-
I did push awhile back for home-made DVI transmitter, but Nockieboy felt at better ease using the TFP410.
Do you happend to have a link? I would be curious to see the one for Antel devices.
Look way back on this thread and I found a public domain HDMI transmitter with audio support written in Verilog for both Intel and Xilinx.
Here are the only links I remember:
https://www.realdigital.org/doc/189f72e0ee822643d7946fb639754841
https://github.com/charcole/NeoGeoHDMI Altera true 480P with embedded audio.
https://github.com/hamsternz/FPGA_DisplayPort
https://github.com/hamsternz/DisplayPort_Verilog
-
https://github.com/charcole/NeoGeoHDMI Altera true 480P with embedded audio.
This is the only implementation for Antel, and it's using diagrams
so I can't really see it. I do wonder though what "true" part means, 480p is the lowest resolution supported by HDMI without pixel repeats (as 25 MHz is the minimum allowed HDMI clock). Sounds kind of cheesy to me if I'm being honest 
Are there any HDL-only implementations for Antels?
As for others, like I said, minimal DVI TX implementation is very trivial for Xilinx 7 series because it's got SERDES which support 10:1 DDR serialization mode, and its output buffers support TMDS IO standard directly, so there is no need for any voltage translation or other analog tricks and you can connect FPGA pins directly to HDMI connector, while it looks like Cyclone V does not support that (at least I was not able to find any mention of TMDS in CV datasheet), so you will need to use additional circuitry to implement HDMI connector. You can take a look at schematic of the board from my signature and you will see just how trivial it is to physically implement the port using 7 series. -
Do you do your layout in KiCAD? If so, do you have your project published anywhere? I can take a look and help if necessary/desired. I love routing. It's my favorite part of the design process.
No, I'm using EasyEDA which is - as best I can tell - very similar to KiCAD, but all online (though there is a desktop version as well). Thanks for the offer of help, let me know if you feel you can get to grips with EasyEDA and I'll give you access to the project
- but I'm not giving up just yet. 
0402 caps? Can they even be hand-soldered?!
Don't worry, if you've got proper equipment (microscope), you can manually solder even 0201. I've done quite a bit of them, though I prefer reflowing.
Looks like another opportunity to push the limits of my soldering skills (and I thought 0603 was small!) 
I don't have a microscope - I'm using a loupe where necessary, but that's about it. What sort of microscope do you use?That is consistent with the point I made above. The only people who choose Antel voluntarily are those who never used Xilinx 7 series. Once you do, you will never want to go back.
Okay, so I've just had a very quick look at the Spartan 7 series - am I reading it right in that it has about 520KB of RAM in it, not included distributed RAM? -
I did push awhile back for home-made DVI transmitter, but Nockieboy felt at better ease using the TFP410.
Do you happend to have a link? I would be curious to see the one for Antel devices.
Look way back on this thread and I found a public domain HDMI transmitter with audio support written in Verilog for both Intel and Xilinx.
Here are the only links I remember:
https://www.realdigital.org/doc/189f72e0ee822643d7946fb639754841
https://github.com/charcole/NeoGeoHDMI Altera true 480P with embedded audio.
https://github.com/hamsternz/FPGA_DisplayPort
https://github.com/hamsternz/DisplayPort_Verilog
Just a note - the NeoGeoHDMI project was shown running from the smallest Cyclone II FPGA in the video. Hardly the most recent of Antel products.
In fact, BrianHG, I have next to no recollection of having a conversation with you about direct HDMI or using a TFP410. That's not to say it didn't happen, of course - I do have a memory like a sieve - but I'm wondering now if it wouldn't be a bad idea. I've no reason to keep the VGA output if I can get HDMI up and running - doing so would save lots of IOs and routing headaches for me at the bottom of the PCB...
EDIT: Of course, when I say HDMI I mean DVI-D.
-
No, I'm using EasyEDA which is - as best I can tell - very similar to KiCAD, but all online (though there is a desktop version as well). Thanks for the offer of help, let me know if you feel you can get to grips with EasyEDA and I'll give you access to the project
I think so as it supports length tuning as well. At the very least I'm hoping to provide some constructive feedback. - but I'm not giving up just yet. I don't have a microscope - I'm using a loupe where necessary, but that's about it. What sort of microscope do you use?
I use relatively cheap x10/x20 stereo microscope (mostly in x10 mode for soldering) - AmScope SE410, it was about US$170 (+ delivery charge) at the time of purchase. If you browse ebay/aliexpress, you can find a ton of options if pretty much the same basic design as mine with all kinds of combinations of objectives, eyepieces and other accessories. One thing I would say from my experience - if I was to buy a brand new one today knowing what I know now, I would buy a version with double arm boom, as it allows more freedom in movement. But it would cost more than a single arm one that I use, so for occasional use single arm is just fine. Also now that I have the microscope, I use it in x20 mode to look at all kinds of fun and interesting things - from my own skin to biological samples (my wife is a biologist, so that makes it extra fun
)Okay, so I've just had a very quick look at the Spartan 7 series - am I reading it right in that it has about 520KB of RAM in it, not included distributed RAM?
That sounds about right for the S100 device, but keep in mind that BRAMs in 7 series are natively 72 bits wide (can be split into two independent 36 bits wide parts), so depending on whether your design actually uses these additional 8 or 4 bits for something (ECC or some other data like flags or whatever), you might end up having less actually available (because remember each BRAM is all-or-nothing, you either use it fully or you don't). That said, since these BRAMs are very fast (depending on the mode of operation and speed grade, it can go from low 400's well past 500 MHz) and can be configured as hardware FIFOs, they are often used as cache or scratch memory, while resorting to external memory for longer term storage. Since even the slowest speed grade supports DDR2/DDR3 memory running at least at 333 MHz (DDR3 can work at 400 MHz for most devices), you can have massive memory bandwidth and very high capacity ( a single MT41K256M16TW-107:P memory chip cost just US$5 and provides 512 MBytes of storage with 16 bit data bus). And since memory controller IP is provided free of charge, you can see that vast majority of 7 series boards have DDR2/3 memory onboard. The only downside is that x16 memory takes up a whole IO bank (50 pins), but if you use Artix in 1mm pitch 256 pin package, you will have 170 IO pins, so losing 50 of them for memory is not a big deal. Also, since 400 MHz is relatively slow for DDR3 (and tracks are typically very short), it's not super sensitive to proper layout and impedance matching. Again, if you care to look at the project in my signature, you will see that DDR2 there works just fine at 333 MHz (package limit) despite me taking several shortcuts in layout and having no termination for address and control lines (except for the clock signal, which is too important to skimp on). -
In fact, BrianHG, I have next to no recollection of having a conversation with you about direct HDMI or using a TFP410. That's not to say it didn't happen, of course - I do have a memory like a sieve - but I'm wondering now if it wouldn't be a bad idea. I've no reason to keep the VGA output if I can get HDMI up and running - doing so would save lots of IOs and routing headaches for me at the bottom of the PCB...
If SERDESes in CV support 10:1 DDR mode, then implementing it will be a breeze as essentially it's nothing more than a very simple encoder connected directly to SERDES (x3 for R, G and B channels), with encoder accepting parallel color data, a video enable flag, and a pair of sync signals (hsync/vsync) for one of the color channels (I think it's a blue one). And of course you will need PLL to create pixel and symbol clocks from your system clock, and finally some sort of FIFO to transfer data from your system clock domain into symbol clock one.
EDIT: Of course, when I say HDMI I mean DVI-D. -
The current design operates based on using 1 gigantic chunk or simple dual-port ram divided down into 15 25MHz ports, 1 125MHz port. Width is not a problem as a write-mask channel exists. Only minor changes to the current pixel writer where you may want to change the current 16 bit width to 32 improving performance there. You might be able to upgrade the current 125 MHz core system with 250MHz ram to 200MHz while running the ram at 400MHz.Okay, so I've just had a very quick look at the Spartan 7 series - am I reading it right in that it has about 520KB of RAM in it, not included distributed RAM?
That sounds about right for the S100 device, but keep in mind that BRAMs in 7 series are natively 72 bits wide (can be split into two independent 36 bits wide parts), so depending on whether your design actually uses these additional 8 or 4 bits for something (ECC or some other data like flags or whatever), you might end up having less actually available (because remember each BRAM is all-or-nothing, you either use it fully or you don't). That said, since these BRAMs are very fast (depending on the mode of operation and speed grade, it can go from low 400's well past 500 MHz) and can be configured as hardware FIFOs.
You could also then widen the external PSRAM unless you want to go to a true DDR 32bit ram setup and run the core ram at 64 bits. You do not need to stretch too much more here in speed, even if you want texture filled polygons as with this setup, you could fill above ~150 million 32 bit pixels a second compared to our current ~100 million 16 bit pixels a second. (Read/modify/write for each pixel) (Yes, better is possible, but a lot of code changes will need to be done and a lot of legacy graphics functions/modes used for small CPUs like Z80s would get pushed out of the way.)
Note that 1 smaller dual port 400MHz 1KB ram would still be need for the palette.
There is no other ram in the system except for a 512 word x16bit FIFO which can be worked around if nessary.
-
No, I'm using EasyEDA which is - as best I can tell - very similar to KiCAD, but all online (though there is a desktop version as well). Thanks for the offer of help, let me know if you feel you can get to grips with EasyEDA and I'll give you access to the project
I think so as it supports length tuning as well. At the very least I'm hoping to provide some constructive feedback. - but I'm not giving up just yet.
Oh, I'm all for constructive feedback - let me know when/if you create an account with EasyEDA and I'll give you access to the project. Or try to, anyway - I tried with BrianHG but I think he had to clone a copy of the project in the end.I use relatively cheap x10/x20 stereo microscope (mostly in x10 mode for soldering) - AmScope SE410, it was about US$170 (+ delivery charge) at the time of purchase. If you browse ebay/aliexpress, you can find a ton of options if pretty much the same basic design as mine with all kinds of combinations of objectives, eyepieces and other accessories.
Will keep my eyes open for a decent one then, thanks.
-
You could also then widen the external PSRAM unless you want to go to a true DDR 32bit ram setup and run the core ram at 64 bits. You do not need to stretch too much more here in speed, even if you want texture filled polygons as with this setup, you could fill above ~150 million 32 bit pixels a second compared to our current ~100 million 16 bit pixels a second. (Read/modify/write for each pixel) (Yes, better is possible, but a lot of code changes will need to be done and a lot of legacy graphics functions/modes used for small CPUs like Z80s would get pushed out of the way.)
Since DDR3 has 8n-prefetch architecture, DDR3 controllers typically runs at 1:2 or 1:4 memory clock rate. Xilinx memory controller can be configured to run at either, but 1:4 mode lines up nicely with 8n prefetch such that each system clock cycle gives you (or writes out) entire 8x data burst (4 memory clocks * 2 xfers per clock). So for x16 physical data bus and 400 MHz memory clock rate you get 16*8=128 bits at 100 MHz, or 64 bits at 200 MHz for 1:2 mode. The total theoretical bandwidth of x16@400MHz DDR3 interface is 400M*2(DDR)*16(data bus)=12800 Mbit/s, so unless you think you will need higher BW, you can get away with x16 physical interface. Also - up to 256Mx16 interface fits entirely into a single IO bank, and you will only need a single x16 memory device, so you can get away without termination for address/data lines. This makes layout much more simple and forgiving as your tracks will be very short. If you want to use more than one memory device in the interface, you will have to do a fly-by routing of address/control lines, and I have my doubts that you will be able to get away without termination at the end of these lines (though we can do some simulations to see if it's possible/feasible).Note that 1 smaller dual port 400MHz 1KB ram would still be need for the palette.
BRAMs in 7 series are 36 Kbits each (dividable into 2 independent block of 18 Kbits each), but of course you can configure each of two ports as 32K x 1, 16K x 2, 8K x 4, 4K x 9, 2K x 18, 1K x 36, or 512 x 72 for 36 Kbits blocks, or 16K x 1, 8K x2 , 4K x 4, 2K x 9, 1K x 18 or 512 x 36 for 18 Kbits blocks.There is no other ram in the system except for a 512 word x16bit FIFO which can be worked around if nessary.
You can use BRAM for that as they have necessary hardware to be configured as FIFO. -
Oh, I'm all for constructive feedback - let me know when/if you create an account with EasyEDA and I'll give you access to the project. Or try to, anyway - I tried with BrianHG but I think he had to clone a copy of the project in the end.
Thanks. I've seen your PM and will take a look at it once I get home. Will let you know if it worked out or not.Will keep my eyes open for a decent one then, thanks.
Before I accidentally run into a video on YT showing it, I was under impression that these microscopes cost a fortune and were far out of reach for a common folks like me (who don't have few millions burning holes in the pocket), so I was really surprised to see that there are now affordable options out there. Granted, ~US$200 is not exactly cheap, but my typical 6 layer board runs not that far away from this amount once postage, taxes and dues are all included, so to me it was definitely money well spent. Now I assemble boards for my commercial customers with it, so it paid for itself many times over since purchase. -
You could also then widen the external PSRAM unless you want to go to a true DDR 32bit ram setup and run the core ram at 64 bits. You do not need to stretch too much more here in speed, even if you want texture filled polygons as with this setup, you could fill above ~150 million 32 bit pixels a second compared to our current ~100 million 16 bit pixels a second. (Read/modify/write for each pixel) (Yes, better is possible, but a lot of code changes will need to be done and a lot of legacy graphics functions/modes used for small CPUs like Z80s would get pushed out of the way.)
Since DDR3 has 8n-prefetch architecture, DDR3 controllers typically runs at 1:2 or 1:4 memory clock rate. Xilinx memory controller can ....
Just so we are clear, that 100 million pixels a second combines a read and write for each 16 bit pixel (ie 100 million random pixel read/write a second, 50 million 16bit blits a second, ~double for 8 bit or less), plus 15x simultaneous 16 bit display pixels per pixel (ie 375 million pixel reads a second) to construct a display. In the current system, using the PSRAM, 1-2 of those 15x 16 bit displays (the other 13-14 are still available using on FPGA ram) + ~1/3 speed for the pixel writer + 8 voice stereo audio with pitch&litude modulation is the ball-park target. (SD-CARD read write bursts and 32bit ALU math-co shares the pixel writer's port) A single DDR3 can do triple that with a comfort zone other than some blits when using rotate will break page boundaries when writing every single pixel unless the writes are done to onboard FPGA ram.
-
A single DDR3 can do triple that with a comfort zone other than some blits when using rotate will break page boundaries when writing every single pixel unless the writes are done to onboard FPGA ram.
To help resolving the straddling pages issue, Xilinx memory controller allows remapping user addresses from default "bank-row-column" to "row-bank-column" order, in the latter case you will be straddling banks as opposed to rows, and since different banks can have different pages open at the same time, you won't end up having to constantly open and close adjacent rows, and instead will be working with two banks in parallel.
Another way to resolve this issue is to implement a cache for 2 pages used in a circular fashion. Initially you load in first page to the cache #1 and write your changes to the cache instead of DDR. As you get close to the end of the page in your processing, you asynchronously load in the second page into cache #2. At some point you will move far enough into the second page to not need the first page anymore so now you can asynchronously commit entire first page from cache #1 into DDR. As you get close the end of the second page, you bring in third page into cache #1. This process then repeats endlessly. You can also expand it to more pages if required. Each page in x16 DDR3 device is 2KB = 16 Kbits long, which fits nicely into one half of BRAM (18 Kbits one). You will only need to have some way of knowing when entire page is completed and can be safely written out to DDR, as well as enough of a head's up to when you will need the next page so that you can read it in before it will actually be required and as such completely hide memory access latency from you main process. Also since you will be reading/writing entire pages, this will also lead to better memory bandwidth utilization, as it was designed exactly for this kind of usage scenario (desktop CPUs access entire cache lines at a time as well).
Also since DDR3 has large capacity, you can do double or even triple buffering to avoid race conditions between your renderer and the output process that outputs the frame to a screen. -
I didn't think I was too bad at routing until I started on these DRAMs. Have been staring at the layout for too long - it's time to ask for help, I think.
Latest attempt at wiring the DRAMs is attached.
Aside from being a complete mess already, I also need to add in two vias for each signal that is currently only on one layer so that the via count for those signals matches the ones that already have two vias?
Looks like I'm going to have to route the chip selects on a third layer to get to the top of the DRAMs. It's funny how all those IOs on the FPGA look like they'd make routing easy, but once you start looking at the detail, you realise that actually you're really restricted in which IO you can use for which job.
-
Arrrggggg.. Ok, if 'asmi' doesn't help you out there, I'll make time toward the end of the week to route the ram for you. For now, try your best with everything else and just leave room for the ram and don't touch the power or GND plane for now.
-
I'm trying to get to the grips with the tool. It looks like differential pairs need to have suffixes _P/_N in order for PCB editor to recognize them as such. Can you please rename all differential pairs so that they would have these suffixes at the end, and push this change into the board? I don't feel confident enough with the tool to do it myself yet.
Also - are you targeting JLCPCB's JLC2313 stackup? This is important to determine the trace geometry for differential pairs as well as for data lines (50 Ohm single-ended/100 Ohm differential). -
Arrrggggg.. Ok, if 'asmi' doesn't help you out there, I'll make time toward the end of the week to route the ram for you. For now, try your best with everything else and just leave room for the ram and don't touch the power or GND plane for now.
Thanks.
Regarding the video output - I'm interested in the idea of driving HDMI directly from the FPGA, if it means I don't need to worry about a TFP410 and can drop the VGA connector (I'll drop it anyway in v.2 once I'm confident the DVI-D will work) - it means I'll have room for the USB connection. The whole video output area of the board looks to be a complete routing nightmare at the moment and my confidence is a little shaken by my attempts at the DRAM.
I'm trying to get to the grips with the tool. It looks like differential pairs need to have suffixes _P/_N in order for PCB editor to recognize them as such. Can you please rename all differential pairs so that they would have these suffixes at the end, and push this change into the board? I don't feel confident enough with the tool to do it myself yet.
Also - are you targeting JLCPCB's JLC2313 stackup? This is important to determine the trace geometry for differential pairs as well as for data lines (50 Ohm single-ended/100 Ohm differential).
Thanks asmi.
Differential pairs can have _P/_N or +/-, so I've changed CKP and CKN to CK+ and CK- for brevity. That was a mistake I made naming those nets - I meant for them to be compatible with the tool, just forgot to add the underscore. Have just tried the differential pair routing tool and it's working (although it's trying to do odd things when connecting to the first DRAM - there is guidance here about how to use the tool).
-
Also - are you targeting JLCPCB's JLC2313 stackup? This is important to determine the trace geometry for differential pairs as well as for data lines (50 Ohm single-ended/100 Ohm differential).
Probably not as I was unaware of it. I'll go take a look at it and see how it compares with the stackup BrianHG has specified and that I'm (trying) to work to. -
Probably not as I was unaware of it. I'll go take a look at it and see how it compares with the stackup BrianHG has specified and that I'm (trying) to work to.
If you are planning to use JLCPCB for manufacturing, this is the best stackup to use for high speed designs as it allows using narrower tracks to reach 50 Ohm impedance. That is because the prepreg is thinner in that stackup.
This EDA is a serious test of my patience
I don't know if it's my PC or what, but it's sooooo freaking laggy - sometimes I have to wait up to 10 seconds for my command to register!
I did connect both memory modules, now will need to connect them to the FPGA. What kind of pin swapping is allowed? I assume all data pins can be swapped around, but what about others? My work file is saved right next to original, since I don't want to screw up others' work.
Also I slightly adjusted positions of these memory chips to align them to a grid, as this makes routing easier. In the future I recommend always aligning parts to a grid.
Finally - how are you planning to assemble these boards? If using hot air gun, I suspect that memory chips are too close to FPGA. But maybe I'm wrong - it's been a while since I soldered BGAs with hot air gun. -
Forgot to mention - just in case you guys don't know - Cypress has published HDL simulation models for their HyperRAM chips - this should help you in developing controller for them.
-
I did connect both memory modules, now will need to connect them to the FPGA. What kind of pin swapping is allowed? I assume all data pins can be swapped around, but what about others? My work file is saved right next to original, since I don't want to screw up others' work.
Just read a few posts up. I write down exactly what pins you are allowed to swap and where within the IO bank.
Only the dedicated '###CLKOUTn/p####' output pins should drive the CLKn/p. (polarity don't care/swappable)
And all the data[7..0] should go to a ####,DQ## pins.
And the RDWS pin should go to a #####,DQS## pin. (could be on a DQ pin as well since we are not using the DQS to time/clock/capture early half-clock reads like with DDR3 ram.)
-
If you are planning to use JLCPCB for manufacturing, this is the best stackup to use for high speed designs as it allows using narrower tracks to reach 50 Ohm impedance. That is because the prepreg is thinner in that stackup.
Makes sense. I really feel out of my depth with all this talk of impedence matching, prepreg thickness, return paths and loops etc. I'm really out on a limb here as this is by far the most complicated and advanced PCB I've ever designed - have been looking for information online so that I can read up on this stuff.This EDA is a serious test of my patience
I don't know if it's my PC or what, but it's sooooo freaking laggy - sometimes I have to wait up to 10 seconds for my command to register!
I had exactly the same problem when I viewed your changes. I think part of the issue was having a selection filter on - when I turned it off, the response time improved dramatically. I guess it doesn't help that it's an online tool and runs mostly in your browser, so it's not going to be as sharp and snappy as a dedicated desktop program. The desktop version they provide for download is basically the EasyEDA web software running in a container as far as I can tell, so may not provide much performance improvement. My original PCB design file seems to work a lot faster, though - maybe use that instead.I did connect both memory modules, now will need to connect them to the FPGA. What kind of pin swapping is allowed? I assume all data pins can be swapped around, but what about others? My work file is saved right next to original, since I don't want to screw up others' work.
Thanks asmi - I've copy-pasted your work into the original PCB which seems to run a lot faster than the work copy for some reason. Feel free to work on the original rather than the copy - I'm not going near the DRAMs until you tell me it's safe to do so, and being online software designed with collaboration in mind, it shouldn't cause any issues. I'm backing up the project regularly, just in case.Finally - how are you planning to assemble these boards? If using hot air gun, I suspect that memory chips are too close to FPGA. But maybe I'm wrong - it's been a while since I soldered BGAs with hot air gun.
Believe it or not, this thought had crossed my mind too. I think at the moment I'm going to get the FPGA SMT-assembled by JLCPCB when the PCB is manufactured. LCSC don't stock the DRAMs we're using when I last checked, so I'll have to source them from elsewhere and hot-air solder them. What's a safe distance to mount them at? Or will I have to use some sort of heat shield to protect the FPGA whilst heating up the DRAMs? Though I guess that won't help with the PCB heating up and stressing the BGA solder connections on the FPGA.
-
Believe it or not, this thought had crossed my mind too. I think at the moment I'm going to get the FPGA SMT-assembled by JLCPCB when the PCB is manufactured. LCSC don't stock the DRAMs we're using when I last checked, so I'll have to source them from elsewhere and hot-air solder them. What's a safe distance to mount them at? Or will I have to use some sort of heat shield to protect the FPGA whilst heating up the DRAMs? Though I guess that won't help with the PCB heating up and stressing the BGA solder connections on the FPGA.
I medium nozzle and plenty of flux like the Louis Rossman videos I've attached should allow you to solder the BGA Ram easily even if it is close to the FPGA. The ram, 5x5 ball, 1mm pitch with liquid flux will melt and center truly instantly compared to an adjacent dry FPGA 16x16 balls, 10 times the area. The absolute worst is that a few balls on the FPGA right next to the ram may temporarily almost go liquid, but, you will not damage anything here or be able to dis-lodge the FPGA from it's secure mounting. It you are really afraid, a small strip of kapton tape on the PCB going over the FPGA preventing the hot air and liquid flux from going under the FPGA will prevent enough heat from getting under the FPGA to melt any of it's balls.
Slowly warming the PCB on a hot plate will help with mechanical stresses, but I don't think this will become too much of a problem as melting a 5x5 ball IC will be close to a few seconds. -
Slowly warming the PCB on a hot plate will help with mechanical stresses, but I don't think this will become too much of a problem as melting a 5x5 ball IC will be close to a few seconds.
Good point, hadn't thought of that - it shouldn't take long to solder at all and, like you say, I can always use some Kapton tape for peace of mind.
Whilst I was checking LCSC for the DRAMs earlier, I noticed that Winbond do a version of the HyperRAM chips that seems to be identical to the Cypress Semiconductor part we'd selected previously. As far as I can tell, there's no material difference between the two chips other than the Winbond one being 60% the price of the Cypress Semi chip. Would that be a suitable alternative? -
Just make absolutely sure you choose the exact part number for 1.8v, 200MHz...
Hmm $4.12 at multiple vendors with stock VS $2.75 where only Mouser has stock.
https://www.findchips.com/search/W956D8
At least they are compatible & I believe there is also 1 more manufacturer of HyperBus ram.You can also change to 1 ram chip and use this part number:
https://www.mouser.com/ProductDetail/Winbond/W957D8MFYA5I?qs=YwPsRIUVAOfDQ6YTWk12AA%3D%3D
It's basically 2 hyper-ram in 1 chip package & @ $4.04, you are saving...
Scrap that, I don't think you can interleave within a single 128mb ram chip. (Unless you place 2 of them for 32mb.)
Safer to use 2 chip and interleave commanding the 2 to maximize hyperbus activity and throughput.
Though, I guess you can just increase the burst size & use data write without initial latency & stick with 1 16mb ram chip. Much easier to route.
-
Just make absolutely sure you choose the exact part number for 1.8v, 200MHz...
Absolutely - the W956D8MBYA5I is the one I'd use; 1.8V and 200MHz interface.Hmm $4.12 at multiple vendors with stock VS $2.75 where only Mouser has stock.
https://www.findchips.com/search/W956D8
At least they are compatible & I believe there is also 1 more manufacturer of HyperBus ram.
ISSI is the third manufacturer of HyperRam, but they're as expensive as Cyprus chips and only go up to 166MHz.You can also change to 1 ram chip and use this part number:
https://www.mouser.com/ProductDetail/Winbond/W957D8MFYA5I?qs=YwPsRIUVAOfDQ6YTWk12AA%3D%3D
It's basically 2 hyper-ram in 1 chip package & @ $4.04, you are saving...
Scrap that, I don't think you can interleave within a single 128mb ram chip. (Unless you place 2 of them for 32mb.)
Safer to use 2 chip and interleave commanding the 2 to maximize hyperbus activity and throughput.
Though, I guess you can just increase the burst size & use data write without initial latency & stick with 1 16mb ram chip. Much easier to route.
I'd like to pretend that I understand all that, but I don't. Having one DRAM chip would reduce cost marginally, but the biggest benefit would be easier routing and soldering. Whether those benefits are offset by worse performance due to lack of interleaving or increased burst size making the controller more complicated, I just don't know enough to determine and will have to be guided by your judgement on that one. 