Asynchronous FIFO as an ice studio block

[Rob Holmes]

Hi all,

I'm really enjoying icestudio and making good progress with my project. I have two queries

1. Is there an asynchronous FIFO available as an icestudio block in any of the current collections?

2. Are there any SRAM controllers available in any of the collections.

Many thanks.

[Jesus Arias]

Hi,

Asynchronous memories are quite expensive, about 2 logic cells per bit. So, I don't think there are such FIFOs in the libraries.

But, on the other hand you can provide different clock signals for the read and write sides of the internal BRAMs, so, a FIFO with synchronous reads and writes is possible.

And SRAMs controllers are quite easy to build, at least when coded in Verilog. The only problem lies in the bidirectional data bus, but now, with the latest toolchain versions you can change the bus direction by simply tristating the bus during reads:

// Top module

// SRAM signals, mapped in .PCF file

output [15:0]A,

inout [7:0]D,

output NRDE,  // read enable, active low

output NWRE, // Write enable, active low

...

// Internal signals

wire wr;  // Write to SRAM if high

wire [7:0]din = D; //Input data bus

wire [7:0]dout; //Output data bus

assign D = NRDE ? dout : 8'bzzzzzzzz; // Floating output if NRDE low

assign NRDE = ~wr;

assign NWRE= ~(wr & (~clk));  // NWRE active only at the end of the clock cycle

...

A Verilog code like this can surely be put inside a "code" block in Icestudio and that's the SRAM controller...

Regards

[charli va]

Hi! Obijuan start a collection around FIFOs i don't use it but i think all are synchronous but probably could help you  https://github.com/FPGAwars/iceStack

Greetings!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/0db7eacc-940d-4fb3-b6dc-e51a535ec2dcn%40googlegroups.com.

[Rob Holmes]

Thankyou all for the answers/feedback/help/patience.

Based on the suggestion for the SRAM controller, which has taken me a few days now to really understand how it can be so few lines lol. I'm a software engineer so changing my mindset to model hardware has/is taking a while.

But i am still unsure about a line in the suggestion and how it maps to the reality of the hardware.

The line is this:

assign NWRE= ~(wr & (~clk));  // NWRE active only at the end of the clock cycle

so in my own controller my first instinct is to do this:

assign sram_we = wr_en ? 1'b0 : 1'b1;

however the applying the suggested version would be this:

assign sram_we = ~(wr_en & (~sys_clk));

 
If my wr_en signal is only active for a single clock cycle, will that statement still enable sram_we for long enough for the write to happen, or it there as a delay to allow any change in the data or address bus to propagate before executing the write.

[charli va]

Hi Rob!,

The basic difference under my point of view is basically the timing control.

This method, assign sram_we = ~(wr_en & (~sys_clk));  ensures the stability of data and address lines by allowing any changes to propagate and stabilize before the write operation occurs. Compared to a straightforward approach that directly uses the write enable signal without considering the clock, this technique offers more precise control over the timing of write operations, crucial for the correct interfacing with synchronous memory like SRAM, and helps in maintaining data integrity by ensuring that the write operation is executed when the system is ready and stable.

On the other hand, the correct statement assign sram_we = ~(wr_en & (~sys_clk));  is all boolean operations at the bit level, which in synthesis will generate a minimum hardware of logic gates. The if-else operation will require a multiplexer and a register, which would introduce delays that may not enforce the timing you need to synchronize with the clock drop and the system could not be enough stable.

Cheers!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/dce21ce7-79a9-4c4c-818e-2135c3fd73dfn%40googlegroups.com.

[Jesus Arias]

Hi,

assign NWRE= ~(wr & (~clk));  // NWRE active only at the end of the clock cycle

This is just a precaution in order to ensure the address is valid some time (half clock cycle) before the write pulse. The address would change on the rising edge of the clock but NWRE only goes low after the falling edge.

But many SRAMs actually have writes triggered by the rising edge of nWRE, and in those cases NWRE=~wr; is enough, so, I'm probably being a bit too paranoid ;)

[Jesus Arias]

After thinking about it a little more I'm sure "nWRE = ~wr;" will not work, even with SRAMs with edge sensitive write-enable.

Suppose you have two writes on consecitive cycles. On ~wr you'll get a wide 2-cycle pulse, but the SRAM requires two rising edges, so, the first value won't get written.

Therefore, the "NWRE = (~wr)|clk;" assignement (this is the same as before, just written as the De Morgan equivalent) is required in order to get a write pulse for each clock cycle wr is active.

The OR with CLK also has many other desirable benefits, like the removal of dirty edges and combinational glitches in the wr signal, or the advancing of the rising edge if wr has long propagation delays.

 Regards

[Rob Holmes]

Thankyou all for the explanations that's really helped and is very much appreciated.

I'm progressing well with a fairly ambitious project, looking forward to sharing it.....

I have however run into an issue, whenever i tristate the IO bus

With this line in place

assign sram_io = wr_en ? data_in : 12'bzzzzzzzzzzzz;

I am unable to read data

if i remove that line then i can read from sram_io fine.... so setting the sram_io bus to 12'bzzzzzzzzzzzz seems to kill it off and i can no longer read from it. :(

Is there a specific version of the toolchain that i need for the tristate to work correctly?

[charli va]

Hi Rob! , what version of toolchain and icestudio are you using?

In other hand how do you define sram_io in your verilog code?

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/ad7859e9-c953-44e0-856d-4a9372c681b5n%40googlegroups.com.

[Rob Holmes]

Ice studio Version 0.11.3w
Apio Version:  0.9.1

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCaFLC5RpRUkYjrQypsBB27meJrSSYBEweZQpYw8yg4gaA%40mail.gmail.com.

[Rob Holmes]

Ah... is this the issue?

[charli va]

Yes!! you need to define this i inout left or right.

Boths are the same funcionality (inout port) only change in wich side appears graphically in the block (for easy connection depending the design).

Try it and tell us!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hmMcW4jprDDJ52TUEYmq2x733cic-tEVqkaONHhno-sg%40mail.gmail.com.

[Rob Holmes]

Hmm no, with that line back in it still doenst work.... I am seeing this in the logs

--------> DEBUG: Llega aqu� 1!!!!
yosys -p "synth_ice40 -top main -json hardware.json" -q main.v
Warning: Yosys has only limited support for tri-state logic at the moment. (main.v:3695)

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYk3q7fVjYgCEFo05u2b_d9A0ydZ6s6o8En4qg9fJhVkg%40mail.gmail.com.

[charli va]

Try to install dev toolchain and try again:

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0gkwL1QFa%2B25u4%3DFordkH4x%3Dr6Jh2KZFBFUQXf%3Dqz09kg%40mail.gmail.com.

[Rob Holmes]

Thanks ill give it a go... because i have a custom board, i have a forked repo of APIO with my board added...

So i have to merge in develop build it from source again and copy it over into the right directory....... 

But i cannot locate my notes on how i built apio from source at the moment... doh.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZrYcX8%2B22m3dqku_scSQaOq6cRrx%2BK3K5jhJ5LYieMHA%40mail.gmail.com.

[charli va]

Hi Rob! your board i understand is an ice40 board? i'm integrating this days Icecream board by Jesús Arias and take advantage of this to include the ability to add custom boards based on supported fpgas without needing to port apio (as in your case).

This week I should have it ready, I'm already very advanced but if you can't wait, another option in the meantime that you can try is to download the 0.1.0 toolchain from here https://github.com/FPGAwars/tools-oss-cad-suite/releases and overwrite the toolchain folder you download in your .icestudio directory, I think this could work (make a backup of the folder you replace already, although in the worst case you will only have to reinstall the toolchain)

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0ijcZRaZk63Z1kN_%3DjsMmVWKq7%3DMXUvHGbzBfYn_NQt3Q%40mail.gmail.com.

[Rob Holmes]

Thats awesome news.... my board uses the iCE40-LP1K-CB121. 

I havent figured out how to (or really looked) get it to upload from icestudio, for now ive been taking the hardware.bin file and programming it via Diamond Programmer via my HW-USBN-2B cable.

"iCE40-IPS": {
"name": "iCE40-IPS",
"fpga": "iCE40-LP1K-CB121",
"programmer": {
"type": "iceprog"
},
"usb": {
"vid": "0403",
"pid": "6010"
},
"ftdi": {
"desc": "(?:Dual RS2232H)|(?:Lattice HW-USBN-2B)"
}
}

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZXqmfQgR_ykWrtEw4EYmmA8Hd1Lrjei4wGQVZ4wFbO_w%40mail.gmail.com.

[charli va]

Great!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0jSti8ZY3HEHvZnXLhwbf3Pwz43%3D_SuGYCcffX9RseC6Q%40mail.gmail.com.

[Rob Holmes]

I updated APIO to 0.9.3 but have hit an issue.

I re-added my board to boards.json then ran

$ pip3 install -U git+https://github.com/myrepo/apio.git@develop#egg=apio

then copied the file over to D:\.icestudio\venv\Scripts

Which is what has worked for me before.... however now on build im getting.

[Mon Mar 25 22:39:40 2024] Processing iCE40-IPS
Error: 'charmap' codec can't encode characters in position 0-79: character maps to <undefined>

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYqpaQRSBmnBf24J_Pd6uDJgN3NG2bpXQOjLeNkfDfLPQ%40mail.gmail.com.

[Rob Holmes]

Apologies.... just needed

set PYTHONIOENCODING=utf-8
set PYTHONLEGACYWINDOWSSTDIO=utf-8

[charli va]

Step by step! 😅. i'm working to include this in the next wips sorry for the inconvenience!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/32f3513f-2a2c-409e-aede-dd24d4be66cbn%40googlegroups.com.

[Democrito]

If you're in a hurry, you can do it manually. Look for "Environment Variables" and click on "New", then copy and paste as shown in the image, making sure it looks the same. Don't include "set".

Copy and paste into the corresponding field:

PYTHONIOENCODING  utf-8

PYTHONLEGACYWINDOWSSTDIO   utf-8

If you have any issues, let me know and I will be more specific and visual.

[Rob Holmes]

Thanks all, got it up and running again.

This is probably not the place for my project specific woes but currently losing my mind trying to get what should be simple working.

I have an Async Fifo and an SRAM controller.... I am attempting to fill the fifo from the SRAM at the start of a 640x480 horizontal line and display the pixels.
Ive reduced it all the way down to just reading the initial random contents of the SRAM memory.

VGA Stream is running at 25Mhz direct from an external clock

SYS_CLK is running at 60Mhz via a PLL derived from the 25Mhz clock.



always @(posedge sys_clk) begin
   if (startLineVGA) begin
        SRAMFifoWriteEnableReg <= 1'b1;     // Start writing data into fifo.
        fifoCounterVGA <= 0;               // Reset the local pixel counter.
   end


  if (fifoCounterVGA > 640) begin
      SRAMFifoWriteEnableReg <= 1'b0;       // Stop writing to the fifo.
  end else begin
      fifoCounterVGA <= fifoCounterVGA + 1;  // increment the local counter.
  end
end

assign SRAMFifoWriteEnable = SRAMFifoWriteEnableReg;            // Turn on and off writing to the fifo
assign SRAMWriteEnable = 1'b0;                                                      // Hard coded for reading from SRAM for now.
assign SRAMReadAddress =   fifoCounterVGA;                               // Set the SRAM read address to whatever the counter is for testing.


what i expect to see is rows and rows of identical pixels as it loops through the frist 640 memory addresses over and over for each scanline.....

However what i actually see is this, stops at what looks like exactly 80 pixels. (off by a factor of 8)



if i change the counter to limit to    "if (fifoCounterVGA > 1280) begin"

then i see this..



if i change the counter to limit to    "if (fifoCounterVGA > 1920) begin"   off by a factor of 3

this seems to fill the screen (with some odd jitter now on some vertical lines)  

I believe the startLineVGA signal is correct as the the colors are the same each time.

its as if the fifo doesnt fill up inline with sys_clk

Obviously you dont have my code, but simple question is

"Should" i be able to read from sram and write to a fifo in a single clock cycle? Or am i fundamentally missing something which is very likely as i only picked up icestudio and verilog a short time ago.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/94fed463-5b0e-4c90-86c4-9537c9e8eb7fn%40googlegroups.com.

[charli va]

Hello Rob, first of all, this forum is the place for any kind of question, project or suggestion regarding FPGAS or any other type of electronic idea or project, microcontroller or others, we are people with common interests and the only thing we need is desire to have fun with what we like ;) So don't worry about this anymore and go ahead with it!

Regarding your final question, if I understand you correctly (I'm not sure I understand your question exactly) I think it is not possible "as is", reading and writing at the same time.

You need to have the data from sram to write to the fifo, and since sram is "synchronous", in normal case you need at least two cycles for this (one to read from sram and another to write to the fifo). Assuming you are able to read from sram in one clock cycle (be careful with that).

On the other hand, depending on your design, you could come up with this strategy, you can read from sram on edge clock rise and write on edge clock fall (the Apple II used a similar trick for video memory):

But for this, your design and hardware must be able to take the data in the necessary timing, make sure of this so as not to go crazy :)

Another possibility would be to consider a simple "pipeline" with a simple register. You should first load the sram to the register and from that first load, in each cycle you could write the data loaded in the register to the fifo and read new data from the sram to the register.

About the jitter in the last image, don't worry at all, it's probably a natural moiré noise or some kind of visual noise effect due to the large number of small colored lines that are displayed together.

About the limit, check your logic code, the initialization of the counters in each row, in your code I don't see how you reset the counters per row and that could be the problem.

Another thing that I think could happen to you is that the sys_clk frequency is not correct, it seems to go 8 times faster than what it shows on the screen, so the counter ends at 80 lines if the limit is 640.

When I work with memories, I usually initialize the memory with an image that fills the area of memory I want to work with and try painting something similar like you on a vga os. So it's very easy to debug this kind of thing because you see what parts of the image you paint (for example, if you go 8 times faster than the painted one, you will see one pixel out of every 8 in the real image), it's just a suggestion.

I hope this will be useful

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0jqdjWoMeQTdMUjpP_vVCD4a6FL9AK5r50%3Dz%2BTPn1BZ-g%40mail.gmail.com.

[Rob Holmes]

Thankyou for this, has been really helpful.... However while working on it ive noticed something which seems a bit odd to me.

Ive tracked down my issue to the Fifo and while trying to debug ive noticed something.

When assigning the output of the fifo to my VGA Stream, icestudio is reporting the 2 BRAM blocks being used as expected.

If i were to make the code unreachable then icestudio is reported NO ram being used, this i understand as i assume its just factored out while generating the bitstream..



But what is confusing me is why it gets factored out if i add in a conditional that could be true or false depending on the state of the system.




Does this mean i definitely have some kind of logical error upstream that means SRAMFifoEmpty is permanently TRUE and never changes?
While i might have some errors, i believe it could at least become false at some point so the factoring out seems to be done in error but i am likely just doing it wrong.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCa%2B_r0%3DdYMWj%2B72aV03F1Xyg47Cu-XvwtD%2BkQk272kUhw%40mail.gmail.com.

[charli va]

Hello Rob!, when we work with verilog, you have to think that the final result is not a code to be executed, but a hardware description.

The process that yosys follows to reach the bitstream, is very different from that of a compiler to go from an executable to an object code. That is partly why one process is called "compile" and another "synthesis."

Since it is a hardware description, although in the source code you put a conditional, if the synthesis realizes that this will never be executed, that portion of hardware disappears from the equation.

On the other hand, yosys knows that it has a number of physical resources and its objective is that the resulting bitstream can go as fast as possible, so even if you define a fifo in what you mentally think will be a bram, if yosys has enough resources it can infer that behavior instead of a bram in pure circuit logic (for example with registers) if in your simulation process when synthesizing you infer that this configuration can be achieved with the resources you have and is much faster than putting the bram.

For this reason, in your example, when changing the variable, it still does not infer the bram, it does not mean that it is wrong, but that it has possibly chosen another more optimal configuration than using the bram.

Another thing that can happen is that when adding the conditional logic, it is impossible for yosys to use or automatically infer the bram and transfer it to combinational logic (in this type of case in which you would like to force the use of bram, you would have to use the ice40 primitives in your case)

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0iiBnF5KL8gm3aDW-yYXYMy0A_F3W%2BY6HPtsmZwc_zphw%40mail.gmail.com.

[Tim Rudy]

Looking forward to the conversation continuing! And the success. Charli's comment led me to see this: https://stackoverflow.com/questions/11130764/why-isnt-this-vhdl-inferring-bram-in-xst

It echoes exactly what Charli said. Conditionals and the arrangement of logic can have a subtle effect. I found this example pretty interesting and revealing. Hardware demands experience, getting help and trying multiple times!

"Moving a line up" out of an if statement, which has to do with defaulting. Making sure there is an else, not just an else if, is a helpful tip. You never want some hardware state unspecified when it can be specified. (However the above else if in your code may not be a problem, I'm just calling attention to the rule of thumb.)

Did you get it to work now...?

[Rob Holmes]

As always thankyou for all your responses...

Ive decided to strip out everything from the project to try and find a solution to some of the mysteries i am facing as i am making multiple incorrect assumptions stacked ontop of each other, so am going to rebuild from the ground up and solve issues as they occur one by one.

The primary issue i am still facing is I am unable to tristate the sram controller's IO pins.

As soon as i include this line 

assign sram_io = wr_en ? data_in : 12'bzzzzzzzzzzzz;

then my display goes blank.
removing it and my test pattern returns.

Here is the stripped down version of my project with only the bare minimum to reproduce my issue.
https://github.com/OpenRetroHQ/iCE40-LP1K-IPS

there is an example of an SRAM controller on the blackice board here where the SB_IO primitives are used, is this how i should be approaching this instead?
https://github.com/mystorm-org/BlackIce-II/blob/77474a3cd72b149cc86b580e151d85ec93c7e440/examples/sram/src/sram_io_ice40.v#L182

Ice Studio Version
0.11.3w202403120303202403120303202403120303
APIO Version
0.9.3

[Tim Rudy]

I would look at this closer if I could right now (I am an interested party trying to test the inout feature of Icestudio, especially internally between modules). For you, I think there are a couple of things to change and test.

1. assign data_out = sram_io;

I would start here. You're assigning an inout wire to one that knows nothing about inout. Wiring them together, that is. I think your original design was to have a reg, whose contents at any given time are either the in data or the out data. That's synonymous with using a "process", the `always` and the `<=`. Then given a reg with that content, one assigns wires - the `assign` part.

  I know you've simplified. But bring back a reg anyway. What I'm thinking (hand-waving here), the warning about subtle things applies to this `assign`, from an inout wire to a normal wire. Maybe electrically, conceptually it makes sense. But maybe the tooling, Yosys, sees the `zzzzz` value and removes the connection, optimizes it out, and what you end up with is as if the `assign` statement never existed.

  Try making the data_out output, in the screen shot, into an inout port. Check my assumption that sram_data_out signal could be nothing at all ("undriven").

        // Set the RGB data to the data from the SRAM.
        RGBStrReg[`RGB] <= sram_data_out;

  On the other hand I'm not sure: With point #2, it may be fine to define data_out as a normal port; where it doesn't have to, and never does, carry a `zzzzz` value:

2. assign sram_io = wr_en ? data_in : 12'bzzzzzzzzzzzz;

This I think is exactly the same issue. `assign` not the way to go. "reg" is the way to go. Making a conditional in a wire `assign` statement... is not as dynamic as it looks from a software perspective. Dynamic would mean the sram_io signal is being decided at each moment, it's in a "process" - whereas the above statement uses a gate (or LUT or even a SB_IO, not sure). So to be true to your design intent, use the reg DataOutReg - and #3 is just a comment:

3. Earlier you had

    if (wr_en == 1'b0)

       DataOutReg <=  sram_io;

    This is a latch. Which I think is fine. Having that `if` represents this logic:

  always @(posedge sys_clk) begin
    if (wr_en == 1'b0)
      dataOutReg <= sram_io;

    else

      dataOutReg <= dataOutReg;

 end

    Right? Because dataOutReg has to transition to something. It's a reg, and in a "process" it starts with the value it had and ends up with an appropriate value at end of the time step. Every if has an else, either implicitly or not.

Sorry to be so theoretical instead of trying this out. 

  Best, Tim

[Rob Holmes]

Thanks for the input Tim, appreciated.

I have pushed a few changes to the REPO based on your feedback, ive re-introduced the PLL sys_clk and reinstated the REG for data_out, and also changed the sram_io wire assignment to be via a reg, also changed data_out to an inOut Right port.

Prior Version : https://github.com/OpenRetroHQ/iCE40-LP1K-IPS/tree/4d4eff56416234e461c097c1f6d4f6006a9e7d7e

Latest Version: https://github.com/OpenRetroHQ/iCE40-LP1K-IPS/tree/ec7df1b7dac05ecdfe8bf1e3f5d63add69f0761f

Still no change. If i uncomment any of the lines ive marked in green, the screen goes blank, and noticeably the PLL and sysclk gets factored out completely during synthesis, 



Im guessing im making a very basic mistake somewhere

Has recibido este mensaje porque estás suscrito a un tema del grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/fpga-wars-explorando-el-lado-libre/kHlstoTgFc0/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/4e211404-6bf1-4008-9dec-d4a1692b5015n%40googlegroups.com.

[Tim Rudy]

Hi Rob, so what is going on with sram_io? It's connected through an FPGA pin to the SRAM IC, which is real? And the SRAM you document that its output is always enabled?

Your controller needs to control what's happening here in your circuit (distributing SRAMDataIn and SRAMDataOut) and it needs to control the SRAM over on the same bus. Disable its output? Maybe there are 2 signals driving sram_io? I can't interpret this really.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0gms_HN%3D%2BMtBLY4CWoPs54CN%3D3TiQ0Ys2gfhkQnUsK3Kw%40mail.gmail.com.

[Rob Holmes]

Hi Rob, so what is going on with sram_io? It's connected through an FPGA pin to the SRAM IC, which is real.
Yes they are wired directly from the FPGA to the SRAM chip.

Dont really want to have to use the SB_IO primitive as it looks like voodoo to me at first glance.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAD6yiBdxDRnS7qQPpzBjC3VObCiOibOiMwk-30Y7aUQ6qDLazw%40mail.gmail.com.

[charli va]

Hi Rob! it's not needed that you fight with SB_IO for this. The "code framework" that Jesús draw at the beginning of this thread should be enought.

I'll try to prepare a testbed to try your design and could to help better, but fot the moment try to fix the next things:

1) You don't use sram_data_in, is correct?

Anyway you need to change the internal name and connect with the output in this way:

If you verify your design you could view that this block present an error in this line before you fix with the code above:

Verify and build present different errors, verify analyze the code syntactically and do a kind of compilation, it is very important that you "verify" always your design and all appears correct before "Build" (synthesys).

2) The second and important error to fix before all, the clk signal for the sram block not exists . You connect a label but has no origin block, in this way, sram block do nothing because has no clock :) i think this label should be "clk".

I recommend you to not fall in errors, change this to sys_clk, and replace all first level labels "clk" for sys_clk. Don't use "clk" as label name to not wrong with real clk wire:

Try it first of all and tell us.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0i6TFYM0Hoi1ANrLX65%2BhiLYNnThNA91BjYpKR5H%2BJp1Q%40mail.gmail.com.

[charli va]

Other thing that i forget, now in you sram block always write:

Keep in mind what you want to do because if you always write you couldn't check the content of the sram.

XD

[Rob Holmes]

I owe everyone here a beer or 5..... thankyou so so much for bearing with me.

I fell into the same trap as before...... wiring up only half of the intended functionality and expecting it to still work as software would...

FInally got it reading and writing...... 

I think when trying to strip it down so it only read from, meant that synthesis was just factoring away what in my mind should have stayed.

So the test code writes out whatever happens to be the default sram contents for the addresses 1 to 640 on each row.

In the blanking period it writes the blue color into SRAM for the first 480 pixels.

And i get exactly what i would expect!!!!!!!

I am so happy i could cry lol....






Again, literally cannot thank everyone enough for taking the time to advise and their patience.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCbKrHz%2BLUwRkfTdRr7QhY2_Wtw0Yd-V_xYK_jOdUf7Pkg%40mail.gmail.com.

[charli va]

You are great Rob!! congratulations!! what you feel when a project works... is indescribable ;)

Keep telling us your progress, it promises to be something interesting!

Cheers!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0jvtKbmF28oTdw9shFwHv2Gn3dTKO3_-SGTMB8d4t1Tzw%40mail.gmail.com.

[Tim Rudy]

Congrats!!

On Apr 3, 2024, at 6:59 PM, charli va <char...@gmail.com> wrote:



You are great Rob!! congratulations!! what you feel when a project works... is indescribable ;)

Keep telling us your progress, it promises to be something interesting!

Cheers!

El jue, 4 abr 2024 a las 0:49, Rob Holmes (<onemano...@gmail.com>) escribió:

I owe everyone here a beer or 5..... thankyou so so much for bearing with me.

I fell into the same trap as before...... wiring up only half of the intended functionality and expecting it to still work as software would...

FInally got it reading and writing...... 

I think when trying to strip it down so it only read from, meant that synthesis was just factoring away what in my mind should have stayed.

So the test code writes out whatever happens to be the default sram contents for the addresses 1 to 640 on each row.

In the blanking period it writes the blue color into SRAM for the first 480 pixels.

And i get exactly what i would expect!!!!!!!

I am so happy i could cry lol....

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCabk4%3DkZK-MTaMKLiKp8Vbf0Kz8A5%2B-QbCGs2g36qR8Sg%40mail.gmail.com.