Nexys Video - mistake in description?

[asmi]

Hi,

I've looked at Nexys Video page: https://digilent.com/shop/nexys-video-artix-7-fpga-trainer-board-for-multimedia-applications/ and noticed that in "Board features" section it says "512MB 800MHz DDR3". While it might technically be correct in a sense than the module itself might handle 800 MHz, it is a well-known fact that Artix spped grade 1 can not drive DDR3 faster than 400 MHz, and so I think advertising it as 800 MHz is misleading, as evidenced by several posts here when I had to correct users claiming they were running DDR3 faster than 400 MHz, or were looking for a way to do so (which does not exist). I think you should be upfront in that DDR3 memory on that board runs at 400 MHz despite using memory devices which are capable of higher frequencies (because devices only supporting 400 and below simply don't exist).

[artvvb]

Hey asmi,

Thanks, we'll get it updated. There's some history of using MHz when MT/s or an equivalent really should have been used instead.

Cheers,

Arthur

[asmi]

5 minutes ago, artvvb said:

There's some history of using MHz when MT/s or an equivalent really should have been used instead.

Yeah, current PC RAM marketing is all over this. But since FPGA designs are very close to hardware, it's important to be more precise even with marketing materials, because I think the kind of people who buy these boards are tech savvy enough for the most part to know the difference between "marketing" MHz and real ones.

[zygot]

3 hours ago, artvvb said:

There's some history of using MHz when MT/s or an equivalent really should have been used instead.

After years of reading posts to the Digilent Forums, I'm not all that convinced that most buyers of Digilent's FPGA products are all that savvy. Even people who can do their homework might be snookered by misleading marketing claims, especially for devices as complex as DDR memory, and not take the time to do their homework.

While MTs/s has an aura of technical profundity to it, it's actually pretty useless as a far as telling potential customers about what kinds of applications the board is suitable for. The Nexys Video DDR on a board designed for Video applications does 800 MT/s and the NetFGPA-1G-CML, a board design as a quad Ethernet NIC does 1600 MT/s... so, quick... which is the more capable board? Well, the Nexys Video has a 16-bit DDR DQ bus, so it has a 1600 MiB/s peak data rate between the DDR and the FPGA. The NetFPGA-1G-CML has an 8-bit DQ bus so it has a peak data rate of 1600 MiB/s. Both of these boards are capable of simultaneously being data sources and sinks. In the case of the Nexys Video this is HDMI or Display IN and OUT ports operating at fairly high data rates. In the case of the NetFPGA board, this is 4 full-duplex Ethernet 1 GbE PHYs plus a PCIe connectors. In both boards, the DDR is, by design, a bottleneck for high performance designs, doing what their names suggest they are supposed to excel at. For experimentation or as an educational platform they are both fine, if expensive. Does anyone really believe that someone without experience in either video or Ethernet applications is really going to work all of this out while trying to decide on a purchase that needs to be made *real soon now* ?

Slimy, misleading marketing hype is, I'm afraid is always going to be thrust into the potential customer's eyeballs, whether intentional or not. The storage media companies have been doing this for decades. They just decide to redefine MB as 1,000,000 bytes and put a teensy disclaimer buried deep in a place where no one is going to read it ( on advice of their lawyers ). The difference may not seem that significant, until you start talking about terabyes of data.

It would certainly be swell if Digilent cleaned up its DDR performance misinformation but I've spent 7 years trying to get them to stop peddling "high speed differential" PMOD interface connectors to no avail. People are still trying to implement LVDS_18 interfaces on boards with no possibility of success. But surprise me Digilent, show us that you can be above the sleaziness level of product promotion.

BTW, the Nexys Video doesn't need to be sold based on misrepresentation or confusing marketing. It's far from the fastest Artix device, but it is the biggest in terms of resources. It lets users experiment with transceivers using the mDP IN/OUT connectors. It has a LPC FMC connector. It's not over priced for the educational opportunities that it affords its users, even if the DDR is anemic as a supporting function for it's fine video capabilities. The NetFPGA has limited usefulness, unless you want PCIe connectivity and 4 1 GbE Ethernet PHYs for very limited NIC designs. Don't buy it unless you are prepared to develop everything from scratch, as if it were a custom prototype and you are the guy who has to see if everything works based on nothing more than the schematics ( and this board has the distinction of having the only schematics with errors that I know of ). The company that contracted for Digilent to design it disavows any knowledge of the board, and Digilent provides no useful support. Having said that, I do use the board for some applications

 

 

Edited June 16, 2023 by zygot

[asmi]

14 hours ago, zygot said:

But surprise me Digilent, show us that you can be above the sleaziness level of product promotion.

Well you can prepare to be surprised:

 

Maybe if instead of those walls of text that nobody reads you would post short messages which are straight to the point and refer to a specific complaint, things would actually improve? If you can't help it, force a limit of 200 words per post so that you can get more to the point, and sound less like an old lone wolf howling at the Moon?

Edited June 16, 2023 by asmi

[zygot]

AaaRooooooooo!

I'm impressed, though it ignored my, belabored to some people, point about MT/s nonsense.

Now about those "differential PMOD" references, and more importantly appearances....

Edited June 16, 2023 by zygot

[zygot]

Anyone, who's owned a dog knows that while the lone wolf (dog) howl starts as a solo it ends up as a chorus as the sympathetic neighbors catch on.

So, does breaking up a long string of text make it easier to digest my wordy attempts at communication for those with brains trained on social media?

[asmi]

8 minutes ago, zygot said:

Anyone, who's owned a dog knows that while the lone wolf (dog) howl starts as a solo it ends up as a chorus as the sympathetic neighbors catch on.

The point is that everyone ignores those wolfs because there is nothing that can be done to get them to stop.

9 minutes ago, zygot said:

So, does breaking up a long string of text make it easier to digest my wordy attempts at communication for those with brains trained on social media?

"Wordy" posts don't bother me unless they are on topic, but most of yours are all over the place and so reading them is a waste of time. And some people will take it as a disrespect of their time with all those irrelevant tangents, which is why sometimes you get a hostile reaction to your posts. So maybe try to be more short and to the point, and less tangents and howling on the Moon?

[zygot]

4 hours ago, asmi said:

"Wordy" posts don't bother me unless they are on topic, but most of yours are all over the place and so reading them is a waste of time.

I believe that you meant to say off-topic.

So, either you didn't bother to read what I posted and just wanted to criticize the length of the post or you'd prefer buying board A, capable of 1600  MT/s over board B capable of 800 MT/s even though board B has 2X the peak data rate because of the difference in DQ bus width? How is this part of the discussion 'off-topic"?

There's a lot more to understanding FPGA-DDR performance than one over-simplified and misleading number. You may not care about that, but I do. DDR devices weren't designed to be connected to programmable devices. I don't now of any DDR3 devices that can't operate much faster than the FPGA that they are connected to on the kinds of boards that Digilent sells.

I don't care at all about people criticizing my posts based on delivery. When someone can't think of any technical issue with the content and then wastes their valuable time to post criticism of the messenger that's a statement about them, not the messenger. I know that you like short posts, unless you're the one doing the posting, but you're the only one complaining about it.

Don't smother the debate with personal grievances. If you've got a problem with an argument, write about that, not about the way that it's presented. What's important for a forum like this one is presenting useful information, not petty nonsense.

Edited June 16, 2023 by zygot

[robfinch]

Okay, I am confused now. DDR RAM AFAIK uses both edges of the clock to transfer data. While the clock is 400MHz using both edges means twice the data is transferred per clock. I think that means that data is effectively transferred at 800 MHz. Since it is a 16-bit bus that is 1600 MB/s.

[zygot]

@robfinch,

What specifically are you confused about? Your analysis is correct; a 400 MHz 16-bit DDR bus  is capable of a maximum of 800 MT/s or 1600 MiB/s ( 400 MHz * 2 transactions/clock * 2 Bytes/transaction ), where Mi refers to 1000000 and MB refers to 2^20 ( 1048576 ). When we are talking about DDR memory. the DDR bus isn't the limiting factor as data transfers are initiated with commands from a controller in the FPGA to a controller in the DDR memory. There's more to the story, and I've raised some of these details in a tutorial that I've posted on the Digilent forums.

For DDR memory interfaces, that 1600 MiB/s figure is the absolute maximum data rate and can only be sustained during bursting read or write operations, and that doesn't include the command time or for read operations the latency from command to data. In addition, DDR requires refresh periods which inhibits data transfer for other purposes.

But your post supports my notion that this isn't all that obvious to most users of Digilent's FPGA boards. It also supports my notion that a single performance claim, like MT/s is not all that useful. In real world usage DDR connected to FPGA devices has a lot of particular details that might have a negative impact on any particular use. This is especially important when there is just one external DDR interface and the user needs to support data going into and out of the same DDR interface. When data is coming from or going to video or Ethernet sinks or sources, this can be very problematic. This is what I described previously. Even though one person thinks that this is off-topic, it certainly isn't if you actually need to implement working projects on platforms that aren't designed by people who do such projects. I suspect that this is why board vendors prefer to market their products with one simplistic number rather than raise awareness of a fundamental weakness of their products that are sold as being suitable for certain applications. 

BTW, very few vendors of cheap FPGA boards even provide support for using a crucial component of what the customer is buying unless they are willing to waste a significant amount of the FPGA's resources with superfluous baggage like a soft processor. Digilent has never been one of the vendors who puts their customer's interest above that of the FPGA vendor's.   

Edited June 18, 2023 by zygot

[robfinch]

Thanks, yes, there are a lot of issues to resolve when using the DDR3 RAM. It is definitely very challenging to make use of the DDR3 bandwidth, especially if multiple devices need to access the RAM. I have been working on a memory controller to make this easy to do which sits between the MIG controller and the rest of the system. It is available at: https://github.com/robfinch/Memory-Cores/tree/main/mpmc10, but is still “in the works”. 

Using the MIG controller the latency is something like 25 clock cycles, although the throughput is single cycle excluding things like refresh and commands. I figure one is doing very well to make use of ½ the max bandwidth in a system with multiple bus masters needing access to the RAM. 1/4 is probably more realistic. I ended up building the multi-port memory controller with a system cache. A lot of bandwidth is made use of by burst fetching multiple 128-bit packets. The MIG controller burst fetches 16 bytes per burst, then the MPMC bursts the burst fetches. Streaming ports in my MPMC fetch 64 * 16 byte bursts or 1024 bytes at a time. With a fixed latency of about 29 clocks to fetch 16 bytes fetching 64 times as much data takes only about 100 clocks. This is not much worse than some of the longer running CPU instructions.

[zygot]

19 hours ago, robfinch said:

I figure one is doing very well to make use of ½ the max bandwidth in a system with multiple bus masters needing access to the RAM. 1/4 is probably more realistic.

All of the projects that I've published use a state machine that uses about 1/4 the maximum achievable bandwidth of FPGA vendor external memory controllers. The example design that the MIG provides runs a the full bandwidth, which works out to about 90% of the peak data DDR bus rate (on average for large blocks of data ), 1440 MiB/s for the Nexys Video board for instance. I've achieved these levels of bandwidths for testing board performance and simple MIG use cases, but for real world designs, like you are working on, achieving timing closure get to be very difficult. It's due to the way that the MIG UI interface works.

The external memory controller for cheap Intel FPGA devices works differently than the AMD/Xilinx one does and exhibits a much lower read latency. It's also a lot harder to use effectively, due to poor documentation laden with errors.

The MIG only supports BL8 mode for any of the devices that I've worked with using DDR3. Some DDR memories are limited to bursting of 8 cycles, but most can do double that or more. Higher burst cycles make for better efficiency and achieving the best performance while simplifying timing closure.

I don't use soft-processor IP in my designs, but I'd think that you'd want to implement a fast BRAM cache with external memory as that's how the devices are designed to work. Caching instructions and data, has it's own issues of course.

Again, some people are enamored with not very helpful stats like MT/s, but for anyone actually trying to use DDR in a real world design things get very complicated quickly. 

I believe that for the kinds of educationally oriented FPGA boards that Digilent makes, a couple of independent SDRAM interfaces would be preferable than one DDR3 memory interface. Yes, the data rates are lower but you can implement more than 1 external memory interface because the pin requirements are lower. Timing is way easier for SDR interfaces and users don't need to be tied to vendor IP. For a board with high data rate external interface sources and sinks this would make more sense. So for something like the Eclypse-Z7, instead of a Z7020 with one PS memory serving PS and PL needs, an Artix device with 2 SDRAM interface that allowed for simultaneous ADC and DAC external memory accesses, would have been a superior approach. I don't think that the Eclypse-Z7 was designed for users however. Terasic sells a number of relatively inexpensive boards with both DDR and SDR external memory.

Edited June 19, 2023 by zygot

[asmi]

2 hours ago, zygot said:

The MIG only supports BL8 mode for any of the devices that I've worked with using DDR3. Some DDR memories are limited to bursting of 8 cycles, but most can do double that or more. Higher burst cycles make for better efficiency and achieving the best performance while simplifying timing closure.

1. No DDR memory supports bursts longer than 8 beats. The only device I know that does is HyperRAM, but that is not a DDR memory but a PSRAM. Those things are inferior to DDR because they are not pipelined and so you can't hide it's very large access time by overlapping it with other transfers (and it makes sense since it uses the same bus for commanding and data, so you can't send commands in parallel with data exchange like you can with DDR), and so very long bursts is the only way to amortize that access latency - unlike with DDR where you can achieve 100% data bus utilization with proper commanding (sans refresh time of course).

2. Higher burst cycles is absolutely not neccessary to achieve better efficiency because DDR memory architecture is pipelined, and so you can send in commands and exchange data at the same time. 

3. MIG is a true 1T memory controller meaning it can send commands in on every memory cycle, so you can achieve near-full bandwidth utilization using both UI and AXI4 shim if you do it right. It also supports dual-rank memories (unfortunately only in form of memory modules out-of-box, but it's theoretically possible to work around that limitation by configuring MIG as if it works with a SODIMM while in reality it will connect to a bunch of discrete modules in two ranks). If you use DMA or other burst-based AXI4 bus master (including those designed by yourself), you can easily achieve 80+% of theoretical max bandwidth. If you use Microblaze, you have to make sure you have IC$ and DC$ turned on and it's line width set to be the same as what single burst of MIG will return, this way it won't hinder performance of other bus masters too much.

4. Since MIG uses regular fabric logic, it's not more difficult to achieve timing closure with it then when working with any other logic. Higher burst cycles (if we pretend for a second that DDR supports that) do not help not hinder timing closure in any way whatsoever. And since AXI4 bus designed such that it allows inserting register slices between master and slave in a way that is completely transparent to both of them, achieving timing closure in AXI4 designs is easier than ever.

5. Access latency is not very important for DDR controller because it's a burst oriented architecture optimized for bandwidth over latency. BTW GDDR memory has even higher access latency - up to 100's of clock cycles, but that allows it to reach super-high bandwidth of 100's of Gigabytes/second.

Edited June 19, 2023 by asmi

[asmi]

2 hours ago, zygot said:

I believe that for the kinds of educationally oriented FPGA boards that Digilent makes, a couple of independent SDRAM interfaces would be preferable than one DDR3 memory interface. Yes, the data rates are lower but you can implement more than 1 external memory interface because the pin requirements are lower. Timing is way easier for SDR interfaces and users don't need to be tied to vendor IP

This is a very stupid idea because SDRAM interface has several times lower bandwidth, there is no way you can stream 1080p video over that interface with the pins budget you have for DDR3. 16 bit SDRAM interface running at 166 MHz will only give you 333 MB/s, while 16 bit DDR3 running at 400 MHz gives 1600 MB/s - so we're talking almost 5 times lower bandwidth for SDRAM for no good reason. So to achieve the same bandwidth as a single 16 bit DDR3 module, you will need FIVE 16 bit SDRAM devices, and a much bigger FPGA package which would actually have enough pins to make such a moster possible. And also MIG is included for free for DDR2/3, but there is no free controller for SDRAM, so it will mean additional headache for Digilent to design and maintain one as robust as MIG - which is not easy and is likely to be quite expensive.

[zygot]

11 minutes ago, asmi said:

No DDR memory supports bursts longer than 8 beats.

You may be correct about this.. not sure why I was thinking otherwise. For now, I'll stipulate that you are correct.

13 minutes ago, asmi said:

Since MIG uses regular fabric logic, it's not more difficult to achieve timing closure with it then when working with any other logic.

I disagree with that premise based on experience. I'm not talking about the MIG controller per se., I'm talking about the logic that controls the MIG and has to work with a number of other interfaces using unrelated clock domains and IO that can appear on any IO bank. For some designs you might be correct, not so for other designs. 

17 minutes ago, asmi said:

Access latency is not very important for DDR controlle

I disagree. Latency is a system issue. Some systems require low latency DDR read operation. Making a broad statement about the MIG controller isn't much value for every particular use of the MIG or external memory.

[asmi]

7 minutes ago, zygot said:

I disagree with that premise based on experience. I'm not talking about the MIG controller per se., I'm talking about the logic that controls the MIG and has to work with a number of other interfaces using unrelated clock domains and IO that can appear on any IO bank. For some designs you might be correct, not so for other designs. 

Like I said, you can transparently add register slices between AXI endpoints if you have trouble closing timing, which makes this whole thing an absolute non-issue, unlike with some other buses. As for working with UI directly, it's not different to any other designs with several clock domains.

9 minutes ago, zygot said:

I disagree. Latency is a system issue. Some systems require low latency DDR read operation. Making a broad statement about the MIG controller isn't much value for every particular use of the MIG or external memory.

If you require a very low latency, you shouldn't use DDR because it was designed for bandwidth, not latency. Latency-sensitive designs need to use something like LRDRAM or even QDRII - the latter has access latency of only 2 or 2.5 clock cycles while running at 500 MHz or even faster.

[zygot]

9 minutes ago, asmi said:

This is a very stupid idea because SDRAM interface has several times lower bandwidth, there is no way you can stream 1080p video over that interface with the pins budget you have for DDR3. 16 bit SDRAM interface running at 166 MHz will only give you 333 MB/s, while 16 bit DDR3 running at 400 MHz gives 1600 MB/s - so we're talking almost 5 times lower bandwidth for SDRAM for no good reason.

I think that you are making what's generally referred to as a "straw man" argument; fabricating a specious scenario that seems to debunk an unrelated statement.

• 166 MHz SDRAM is a fairly slow grade for what's available.
• SDRAM devices aren't limited to 16-bit data widths.
• And how doe you calculate your assertion that 333 MIB/s is too slow for 1080p video; assuming that you are using a narrow, slow SDR memory interface? So, by your calculations a 32-bit SDRAM interface that only runs at 166 MHz can do 666 MiB/s which is fast enough to support 2 channels of 100 Msps 16-bit ADC or DAC data. My reference was for educational FPGA platforms. Most such project s don't require anything better. If you don't need vendor IP for external memory, then so much the better for an "educational" FPGA board.

[zygot]

3 minutes ago, asmi said:

Like I said, you can transparently add register slices between AXI endpoints if you have trouble closing timing, which makes this whole thing an absolute non-issue, unlike with some other buses.

I don't use AXI busses for non-ZYNQ designs. I've never seen a company use IPI or AXI busses for commercial designs for a variety of reasons. The IPI flow isn't all that it appears to be. Making timing with poor constraints does not result in a robust design. Adding registers or pipelining is a limited technique that doesn't necessarily resolve system timing closure; this depends on a lot of factors.

8 minutes ago, asmi said:

If you require a very low latency, you shouldn't use DDR because it was designed for bandwidth, not latency. Latency-sensitive designs need to use something like LRDRAM or even QDRII - the latter has access latency of only 2 or 2.5 clock cycles while running at 500 MHz or even faster.

Great! Publish your example project using QDRII on a Nexys Video board. QDRR is mostly found on FPGA based NIC cards and is a low density ( 1 MB or so ) very high power dissipation design solution. For sure, the basic idea that a design should use resources that are best suited to an application is unassailable. In fact, that's been at the heart of everything that's I've posted to this thread. With a board like the Arty A7-100T or the Nexys Video, you have to work with the resources that are available. My professional experience is designing application specific hardware not general purpose boards for educational experience. I'm not suggesting that Digilent's FPGA boards are lousy, just the marketing that promotes misleading ideas about what they are good for.

[asmi]

3 minutes ago, zygot said:

I don't use AXI busses for non-ZYNQ designs.

That's your problem.

4 minutes ago, zygot said:

I've never seen a company use IPI or AXI busses for commercial designs for a variety of reasons. The IPI flow isn't all that it appears to be.

I've seen exactly opposite. All my customers for whom I designed boards use AXI and IPI flow.

4 minutes ago, zygot said:

Making timing with poor constraints does not result in a robust design.

That is irrelevant point.

5 minutes ago, zygot said:

Adding registers or pipelining is a limited technique that doesn't necessarily resolve system timing closure; this depends on a lot of factors.

It always helps with timing closure because placer can place those slice registers inbetween of long timing paths.

6 minutes ago, zygot said:

Great! Publish your example project using QDRII on a Nexys Video board.

That board is designed for video processing - hence the name "Video".

7 minutes ago, zygot said:

QDRR is mostly found on FPGA based NIC cards and is a low density ( 1 MB or so ) very high power dissipation design solution.

Not true - MIG supports densities up to 144 Mb (which can be used as 128 Mb with ECC).

9 minutes ago, zygot said:

I'm not suggesting that Digilent's FPGA boards are lousy, just the marketing that promotes misleading ideas about what they are good for.

I actually think that this board is an exception because the name clearly conveys what it's primarily designed for. Some other boards are much more vague.

[asmi]

27 minutes ago, zygot said:

I think that you are making what's generally referred to as a "straw man" argument; fabricating a specious scenario that seems to debunk an unrelated statement.

It's simply the case of you having no idea what are you talking about. I actually did some research before answering, unlike you.

27 minutes ago, zygot said:

166 MHz SDRAM is a fairly slow grade for what's available.

It's about the maximum of what SDRAM devices can do. There are a few 200 MHz devices out there, but they are few and far in between. Take a look at DK or Mouser and see for yourself.

30 minutes ago, zygot said:

SDRAM devices aren't limited to 16-bit data widths.

I never claimed they are.

30 minutes ago, zygot said:

And how doe you calculate your assertion that 333 MIB/s is too slow for 1080p video; assuming that you are using a narrow, slow SDR memory interface? So, by your calculations a 32-bit SDRAM interface that only runs at 166 MHz can do 666 MiB/s which is fast enough to support 2 channels of 100 Msps 16-bit ADC or DAC data.

32bit SDRAM interface can not be implemented in a single IO bank - there are not enough pins. And 16 bit DDR3 interface can.

31 minutes ago, zygot said:

My reference was for educational FPGA platforms.

There is no point to "educate" about long obsolete memory technology. Even DDR3 is getting there, but here there is a hardware limitation in that 7 series FPGAs are long in the tooth my themselves and don't support more modern interfaces.

33 minutes ago, zygot said:

Most such project s don't require anything better.

That is an unsubstantiated claim to put in mildly.

33 minutes ago, zygot said:

If you don't need vendor IP for external memory, then so much the better for an "educational" FPGA board.

You still need a controller for SDRAM, and since Xilinx doesn't provide one, Digilent will have to chime in, design one and make it available. Otherwise there will be on end of topics "How to I use memory?". And no, it's absolutely not better for educational FPGA boards, infact it's really bad for any board.

[zygot]

6 minutes ago, asmi said:

That board is designed for video processing - hence the name "Video".

And what does that statement have to do with QDDR memory? Nothing. I can think of a lot of video applications that require very low latency high density external memory storage. Quick, name all of the cheap FPGA boards with QDDR memory that Digilent or a similar vendor sells.

I can't think of a good reason to respond to your other comments, but it is refreshing to have you actually try and have an intelligent conversation rather than the usual stuff.

[asmi]

8 minutes ago, zygot said:

And what does that statement have to do with QDDR memory? Nothing. I can think of a lot of video applications that require very low latency high density external memory storage

Then this board is not appropriate for those designs. Unless you can come up with a way to remove that requirement. As I said above, graphics cards use GDDR memory which has VERY long access latency (compared to DDR3), yet they obviously found a way to deal with it. But in any case it's not a fault of DDR as technology that someone tties to use it contrary to scenarios which it was designed for.

10 minutes ago, zygot said:

Quick, name all of the cheap FPGA boards with QDDR memory that Digilent or a similar vendor sells.

I can't think of one, but you can always design one.

12 minutes ago, zygot said:

I can't think of a good reason to respond to your other comments, but it is refreshing to have you actually try and have an intelligent conversation rather than the usual stuff.

I wish you would provide something to have an intelligent conversation about, as opposed to usual stuff.

[zygot]

2 hours ago, asmi said:

I wish you would provide something to have an intelligent conversation about, as opposed to usual stuff.

So, you do have a sense of humor.

If nothing else I've got you to support, in your own words, my argument that MT/s isn't particularly informative when choosing an FPGA platform, nor is talking about details that are informative "off-topic".

Edited June 19, 2023 by zygot