The BlackEdge project

[daveshah]

A USB 3.0 carrier board would not use the SERDES, I presume, but a interface chip such as the FT60x or CYUSB301x series, which would also be considerably easier to work with.

[Folknology]

A USB 3.0 carrier board would not use the SERDES, I presume, but a interface chip such as the FT60x or CYUSB301x series, which would also be considerably easier to work with.

Yes an external USB3 chip with parallel interface, we could also deal with the USBC Power requirements

[Folknology]

In many cases USB2.0 HS is more than good enough at 480 Mbits/sec for many applications and considerably less cost (not to mention less layout and manufacture issues)

[lawrie]

Do you have a recommended way to connect an LCD display, optionally with a touchscreen, to the board? There are lots of applications that can use that, such as a games console, phone, oscilloscope or other instrument.

Also what would be the recommended way of getting wireless comms capability such as Bluetooth and Wifi. Would an ESP32 co-processor be the best solution for that?

How would you get an Ethernet IP connection?

[Folknology]

Do you have a recommended way to connect an LCD display, optionally with a touchscreen, to the board? There are lots of applications that can use that, such as a games console, phone, oscilloscope or other instrument.

We have an FPC Mipi connector that can be used for this as well as a more generic FPC

[daveshah]

This should support up to 800Mbit/s on the ECP5, enough to use typical 720p MIPI DSI phone or tablet screens.

Gigabit Ethernet could be added easily enough with a RGMII PHY on a carrier.

[Folknology]

Also what would be the recommended way of getting wireless comms capability such as Bluetooth and Wifi. Would an ESP32 co-processor be the best solution for that?

I am playing with the Option of purchasing with and without WiFi, I just have to solve the logistics of that.

[Folknology]

How would you get an Ethernet IP connection?

This would be done on a carrier board (primarily due to connector size!)

[lawrie]

And do you have a recommended way to have a battery-driven portable device based on the board.

[Folknology]

A Coms carrier board would be nice for instance, that would have USB 3.0 and Gigabit Ethernet on it along with any number of other useful things like Canbus for example

[Folknology]

And do you have a recommended way to have a battery-driven portable device based on the board.

My gut feeling would be do this on the carrier board, particularly if you want battery management, monitoring and charging..

BTW the core board can be powered by the carrier, it also has ADCs which could be handy for this application.

[BigEd]

Thanks for the new thread - a very attractive product and an interesting discussion!

[BigEd]

What features will BE have
Although exact features are still in the air, I expect at least 2 initial configurations a 12K and a 45K.

* Both will have DDR Ram in 10s of megabytes range more on the 45K than 12K.

As DDR isn't so easy to use, is there a DDR controller within the open source tool chain? How wide might the DDR be? 32 bits would be good!

For the on-chip RAM, I found a table here, which says LFE5U-12 has 32 blocks of 18kbit RAM, which gives 64k bytes, and LFE5U-45 has 108 blocks, which gives 216k bytes. These block RAMs seem to be variously described as sysMEM, EBR and Embedded Block RAM.

For calibration, an Acorn BBC Master 128 with a filesystem ROM and a 64k second processor with a small boot ROM would pretty much use all the on-chip RAM. Or to put it more positively, the ECP5 45k chip is big enough to contain that whole system.

[lawrie]

A related question is what latency will the DDR Ram have.

I am interested in porting more retro computers , games consoles, and arcade machines to the BlackEdge, either using HDMI or an LCD. The biggest source of these seems to be the MISTer project that runs on Terasic DE10-Nano. The MISTer project cannot use the DDR3 Ram on that device and needs external SDRAM because, as it says:

Whilst the DE10-nano has fast DDR3 memory, it cannot be used to emulate a retro EDO DRAM due to a high latency and shared usage from ARM side. This SDR SDRAM on daughter board is required for most cores to emulate a retro memory module.

I would like to know if there will be a similar problem with BlackEdge?

The other issue with porting a lot of the MISTer cores in that many of them use VHDL and SystemVerilog.

[Folknology]

As DDR isn't so easy to use, is there a DDR controller within the open source tool chain? How wide might the DDR be? 32 bits would be good!

DDR will be arranged as 16 bit data bus we will have an opensource Verilog module

[BigEd]

DDR will be arranged as 16 bit data bus we will have an opensource Verilog module

Thanks - looks like two words in an access is the minimum, so that becomes a 32 bit access! There is indeed the question of latency though - for conventional computing, a small cache made from distributed RAM should help a lot, but for cycle-accurate retrocomputing, might be tricky to get deterministic accesses with the necessary timing.

[Folknology]

@lawrie not sure what the issue is but shared usage from the ARM side sounds suspicious, looks like the DDRAM is connected to the ARM so the FPGA has to go through it maybe? That isn't an issue for BE

[lawrie]

This is the best description I could get from the atari-forum.com:

Built-in DDR3 memory has hardware controller and it's shared between ARM and FPGA. On FPGA side you have a nice convenient interface which is close to SRAM interface. So you don't have to worry about SDRAM complexity at all. Also you don't need to worry about refresh. Everything is done automatically on hardware level.
So, from first sight, it looks exciting. Evil comes when you start to use it. Soon you will realize that response time is pretty bad. Response time is not stable and varying from acceptable to unacceptable ranges, so even ZX Spectrum on standard 3.5MHz speed cannot be implemented.
Retro systems have used Asynchronous EDO DRAM. Although it was slow RAM, it provided a fixed access time for any RAM cell. Starting from SDR SDRAM chips started to use a burst transfer where access to a single cell takes almost the same time as access to 4-8 sequential cells. If system is optimized to access to a group of cells then it's much faster with SDRAM. Manufacturers started to rate the speed based on burst access and show a very big numbers like 10-20 times faster, but random access remained at the same level as old Async.DRAM.. So, if system access the RAM randomly by single cells then SDRAM is not faster at all. It even can be slower because requires a lot of clock cycles from starting access to get a first data.
When memory migrated from SDR to DDR, the burst became even longer and more cycles required to get the data. Thus even DDR3 on DE10-nano has whooping 800MHz clock, it's slower than DRAM on old good ZX Spectrum in terms of random single cell access

While relatively old SDR SDRAM also has same problem, it's still faster than DDR3 with random access. So, SDR SDRAM is still useful for many tasks where DDR cannot fit. That's why still many FPGA boards from Terasic have SDR SDRAM additionally to DDR SDRAM.

It sounds as if shared usage with the ARM is part, but not the whole of the problem.

[Folknology]

So for gaming purposes on say a BE, the video part could be optimised as @BigEd mentions using the Embedded Block Ram which can be configured as Dual or single Port, other parts could be mapped to other memory choices depending on optimisation requirements.

BTW it's worth having a flick through TN1264 about the ECP5 built in memory

[daveshah]

With a controller optimised for latency rather than throughput, I think it should still be possible to see DDR2 latencies below 100ns. But BRAM should go a long way too.