GOWIN FPGA

[ali_asadzadeh]

Based on what quantity? Tx!

Around 100 to 1K units, also I think the sample prices is the same too.
They are chinese non-US company, they usually charge very low, the volume is effective in more than 10K units I believe, under 10K everything is the same price, almost no matter the volume Not to mention I could get samples for free

Also I believe the price matters where you live

[FrankBuss]

Around 100 to 1K units, also I think the sample prices is the same too.
They are chinese non-US company, they usually charge very low, the volume is effective in more than 10K units I believe, under 10K everything is the same price, almost no matter the volume Not to mention I could get samples for free

Also I believe the price matters where you live

Did you get the quote from Gowin? I guess the distributor I got the prices from, makes a nice profit then

[ali_asadzadeh]

Did you get the quote from Gowin? I guess the distributor I got the prices from, makes a nice profit then

It's from their distributor, try to change that, also they have a website with very similar prices that sells them.

see these links
https://www.edgeelectronics.com/fpga/gw2a-lv18lq144c7-i6/
https://www.edgeelectronics.com/fpga/gw2ar-lv18lq144c7-i6/

The version that you want is around 4USD
https://www.edgeelectronics.com/fpga/gw1nr-uv4qn88c5-i4/

[TimCambridge]

It's from their distributor, try to change that, also they have a website with very similar prices that sells them.

Did you discover the lead times for the various families of parts?

[FrankBuss]

The version that you want is around 4USD
https://www.edgeelectronics.com/fpga/gw1nr-uv4qn88c5-i4/

No, this is the SDRAM version. The version I asked for was the GW1NR-UV4QN88P (note the additional P at the end), but this is unobtanium anyway. This might explain the difference. But thanks, for this price difference it is worth thinking about if I could do the same with SDRAM, and maybe some BRAM for caching.

BTW, they told me that the PSRAM version is using the W955D8MBYA memory inside, couldn't find this information in the Gowin datasheets. They sent me a preliminary Winbond datasheet of it, where it was called "x8 IO pSRAM". But it doesn't really have a classic SRAM interface. Looks like in the current datasheet, with the same pinout and content, it is called "HyperRAM". I wish everything would be SRAM and fast, would be much easier. At least HyperRAM is simpler than the usual SDRAM interface, but it requires 12 clocks worst case from chip select to data out, if a refresh latency is required.

[iMo]

I worked with PSRAM in past (xilinx<-> 48ball 75ns psram). The interface was standard SRAM, worked fine, the only restriction is the R/W cycles cannot be longer as some specified time because it is dram inside.

It could be the GOWIN is using FPGA chip stacked with a separate DRAM/PSRAM chip (piggybacked chips, pretty popular, ie the GD32F103 chips).

Look at the PSRAM module description in the FPGA's DS, as I can remember the interface is more complex than the actual psram's W955D8MBYA chip ball count.

[ali_asadzadeh]

I have downloaded Their EDA and I'm taking a look at it, Also I got their License too, and have applied the gowin license, Unfortunately I can not find the place to add the gowin Synplifypro license (which I got from them too), I have emailed them, but I think their response time is about 24-48 hours, how did you apply the Synplifypro license?

[FrankBuss]

You have to set the LM_LICENSE_FILE environment variable, e.g. to C:\Gowin\gowin_Synplifypro_xx.lic, if you saved the licence file in the gowin directory under the name gowin_Synplifypro_xx.lic.

[ali_asadzadeh]

You have to set the LM_LICENSE_FILE environment variable, e.g. to C:\Gowin\gowin_Synplifypro_xx.lic, if you saved the licence file in the gowin directory under the name gowin_Synplifypro_xx.lic.

Thanks! you saved me a few days

[ali_asadzadeh]

Am I doing it right? the Synplifypro produce the results so fast! almost like a compiler, under 10 seconds for the examples, or did Xilinx and altera did shit into their software

Also what a beauty is the GW2AR with internal SDRAM and a nice price tag do we have altium libraries?

[OwO]

I've been playing with the gowin software and so far my impressions are:

1. The place & route is really bad. I tested a simple 32 bit adder (fed by a shift register) which achieves a Fmax of only 280MHz on GW2AR. I then did some hand placement and got to a Fmax of 360MHz. The software P&R put registers all over the place and nowhere close to the adder. It looks like the FPGA itself is quite capable (assuming the timing characterization is accurate that is), almost comparable to Xilinx 7 series (which achieves 380MHz Fmax on the same circuit on Artix-7 with Vivado P&R, hand optimization could not improve it further).

2. The FPGA architecture is quite abnormal. Xilinx has had 6-input LUTs since 65nm but these are still on 4-input LUTs, which means (in theory) worse timings but better resource utilization. I had the impression that routing delay usually dominates so you want to pack as much logic into a LUT as possible which is why Xilinx went with 6-LUT very early. The other peculiarity is that the gowin FPGA seems to lack enough flipflops because my FFT core which uses a mostly correct balance of LUT/FF on 7 series uses twice as many flipflops in percentage as it does LUTs on the gowin FPGA. If you look at the device map you'll see 1 out of 4 CLBs have no flipflop (!!!)

Overall I think the most pressing issue is the crap software P&R. I can only get my FFT core up to 200MHz on the gowin device after many rounds of timing whack-a-mole. For shits I tried the gowin FFT ipcore and it only goes up to 90MHz  and isn't even a full-rate streaming design .

[OwO]

Also does anyone have some idea as to why this is a 55nm chip but runs at a 1.0V core voltage and still seems to be pretty fast? Same with the anlogic ones. Spartan 6 was 45nm and ran on 1.2V. What kind of process is this? Maybe something with thin gate oxide but still large feature size?

[iMo]

I think 55ULP is the same as the 40nm ULP (interestingly the 55nm is not listed there):

https://www.tsmc.com/english/dedicatedFoundry/technology/logic.htm#

[ali_asadzadeh]

I've been playing with the gowin software and so far my impressions are:

1. The place & route is really bad. I tested a simple 32 bit adder (fed by a shift register) which achieves a Fmax of only 280MHz on GW2AR. I then did some hand placement and got to a Fmax of 360MHz. The software P&R put registers all over the place and nowhere close to the adder. It looks like the FPGA itself is quite capable (assuming the timing characterization is accurate that is), almost comparable to Xilinx 7 series (which achieves 380MHz Fmax on the same circuit on Artix-7 with Vivado P&R, hand optimization could not improve it further).

2. The FPGA architecture is quite abnormal. Xilinx has had 6-input LUTs since 65nm but these are still on 4-input LUTs, which means (in theory) worse timings but better resource utilization. I had the impression that routing delay usually dominates so you want to pack as much logic into a LUT as possible which is why Xilinx went with 6-LUT very early. The other peculiarity is that the gowin FPGA seems to lack enough flipflops because my FFT core which uses a mostly correct balance of LUT/FF on 7 series uses twice as many flipflops in percentage as it does LUTs on the gowin FPGA. If you look at the device map you'll see 1 out of 4 CLBs have no flipflop (!!!)

Overall I think the most pressing issue is the crap software P&R. I can only get my FFT core up to 200MHz on the gowin device after many rounds of timing whack-a-mole. For shits I tried the gowin FFT ipcore and it only goes up to 90MHz  and isn't even a full-rate streaming design .

That's cool, is your FFT core open source?

[OwO]

That's cool, is your FFT core open source?

Yes it's under github user gabriel-tenma-white. Some things are still WIP, namely the large FFT in DRAM stuff.

[ali_asadzadeh]

Thanks, Is this the link?
https://github.com/owocomm-0/fpga-fft

[OwO]

Yes

[SiliconWizard]

Not bad.

Just took a look at a few source files. There's something I find a little odd about your code style though. You use no or very few "process" constructs and write many assignments with "when rising_edge(xxx)" directly in the architecture's body instead. I guess it's equivalent in the end, but it looks odd. Any reason for this style?

[OwO]

Not bad.

Just took a look at a few source files. There's something I find a little odd about your code style though. You use no or very few "process" constructs and write many assignments with "when rising_edge(xxx)" directly in the architecture's body instead. I guess it's equivalent in the end, but it looks odd. Any reason for this style?

Finally someone noticed my unusual VHDL coding style 

The main reason is I prefer to think in terms of circuits rather than a series of operations like in programming. To me
a <= expression when condition and rising_edge(clk)
just means to create a flipflop fed by a combinational "expression", and with clock enable fed by "condition".

If you look at this code:

Code: [Select]

process(clk)
begin
if(rising_edge(clk)) then
if condition1 then
result <= func(a+x);
elsif condition2 then
result <= func(a+y);
end if;
end if;
end process;

It's ambiguous exactly what hardware it will generate; there will be a mux driven by a combinational function of condition1 and condition2, but it isn't clear if the mux will be before the adder, before func, or after func. There is also an implicit clock enable generated because "result" isn't assigned from all branches.

If I rewrite that snippet my way it would be:

Code: [Select]

muxXY <= x when condition1 else y;
sum1 <= a+muxXY;
result <= func(sum1) when (condition1 or condition2) and rising_edge(clk);

When you look at this code you can just visualize the circuit in your head, and you quickly realize you have a LONG combinational path of a mux feeding an adder feeding a combinational "func". You can also see that there are two paths, a data path and a clock enable path. The clock enable path is short and the data path is long, which you won't easily see with the process version. You can also more easily see exactly where your registers are this way and know what paths may be a timing problem before synthesis.

This style of coding and way of thinking was actually influenced by a professor at the university I went to; he always complained about computing science students in his class who design hardware as if they are writing code. His words were "when you write HDL you should imagine a circuit in your head, not an algorithm or a program".

I have just recently gotten into a habit of drawing a block diagram before writing any code, and by the time I actually write code it's simply a transcription of the diagram. Usually I will have a pretty good idea of how many LUTs a circuit will use before synthesizing it, and I can also design with specific FPGA primitives in mind like the SRL16 (an addressable shift register using 1/2 of a LUT). For example I had just finished designing and verifying an AXI skid buffer based on the SRL16 that uses about a half the number of LUTs compared to the Xilinx one and also fully registers all ports.

I would definitely recommend doing things this way if you are starting out with FPGA design; it should generalize well to verilog as well and you will be able to make designs running at 400MHz rather than <100MHz 

[SiliconWizard]

Thanks for the detailed answer.

I get your point. I can't say I fully agree with it though (not feeling like exposing in details why now, and it would also be off-topic), but I get it.

Just a couple quick remarks then:
- The style is so unusual that it's bound to probably confuse colleagues if you're going to work in teams, and likewise, you're probably going to have a hard time convincing others to adopt your style;
- It may also confuse simulation tools, or at least make the simulations much less efficient (so: much slower);
- It may hinder optimization at the synthesis level, or possibly on the contrary make it way better. That I just don't know, but for the tools not "seeing" any process could possibly trigger uncommon behavior;
- It looks a lot less structured to me (that may be a bit subjective);
- You seem to consider the fact that inferred latches are not going to happen with your style. Alright. But there are simple ways to avoid them when using processes as well;
- As to the "order" or organization of logic blocks, I'm really not convinced it will really make any difference when using modern tools;
- And finally, even though making digital designers think about the hardware is a good thing generally speaking, I don't think they should "overthink" this either at all times. It's good to grasp the concepts and know how to use them, but OTOH thinking too close to the hardware all the time is not very scalable for more complex designs. Yes it can help when you're trying to optimize for speed... but complex digital design should not be conducted just like analog circuit design for instance, so I think you still have to know how and when to use more abstract constructs.

Just the way I see it.

[Berni]

I'm not all that experienced with VHDL, but it does look a bit harder to read when you have the clock edge mixed into to the statement like that.

Don't think Verilog has any way of adding clock sensitivity mixed into a statement in a similar way, but i suppose you can get the same end result by stuffing each thing into its own mini"always" statements like this:

Code: [Select]

always @(posedge clk) if(condition1 || condition2) result <= condition1 ? func(a+x) : func(a+y);

Tho its a bit hard to read so spreading it out like in your example makes it a bit more readable:

Code: [Select]

assign mux = condition1  ? x : y;
assign sum = a + mux;
always @(posedge clk) if(condition1 || condition2) result <= sum;

It is a more compact way of writing it and does mirror the implementation better, but i still think its a bit hard to read when you are just trying to figure out what it does by looking at it. Maybe its a bit better than in VHDL because the clocked part is clearly visible due to needing a different type of statement (But that's probably just my personal taste). To be honest i think both VHDL and Verilog are not all that great of a language. I tend to use Verilog only because it looked slightly less terrible at the time, not because it would seam like an actually good language.

So yeah i tend to prefer writing more drawn out code like that in an futile attempt to make these HDL languages a bit more readable.

[OwO]

I think I just prefer to see flipflops explicitly spelled out rather than defining some logic to "happen at the rising edge"; for example I would like a syntax like:

Code: [Select]

result <= DFF(clk) << sum;Which makes it more clear there is a flipflop/delay from sum to result, and could also allow more than one flipflop on one line:

Code: [Select]

result <= DFF(clk) << func(DFF(clk) << a, DFF(clk) << b);
The other major difference is that when you have if/case statements in a process it's as if entire blocks of code are swapped out depending on the condition, which I find unphysical and unintuitive. IMO you should only ever assign to a signal once; a signal assignment isn't like assigning a value to a variable but rather driving a signal onto a wire, therefore multiple drivers or "swapping out" drivers is unphysical (there are no tristate buffers inside an FPGA). Inside a VHDL process you *can* assign to a signal twice and the synthesizer will create intermediate signals for you. I have actually tried using "process" a few times and found it's too easy to create bugs this way. I prefer to see an error when there are multiple drivers on a signal.

In the dataflow syntax when you write:

Code: [Select]

mux1 <= a when condition else
               b when condition2 else
               c;
"mux1" is always driven, and it is the source of the signal that's being swapped with a mux rather than the assignment itself, which I find easier to visualize.

[Berni]

Well in Verilog the usual way of making a latch is using an if statement, but it could be done without one:

Code: [Select]

assign mux = condition1  ? x : y;
assign sum = a + mux;
always @(posedge clk) result <= (condition1 || condition2) ? sum : result;

This should be more true to the actual implementation inside the FPGA (I think clocked latches are a D flip flop with a MUX that loops its output into input when its supposed to hold state), but i think this makes it even more difficult to read.I agree that HDl languages should be written with the underlying logic implementation in mind, but the way these languages don't seam to make for all that clear code when things are written strictly implementation oriented.

I thought Altium Designer did a nice move in this regard by introducing schematics to HDL in a way that actually works. Its a "language" that works well for describing digital logic as implemented in a clear easily readable way. Too bad they pulled the plug on that just as it was starting to show promise.

[Bassman59]

If you look at this code:

Code: [Select]

process(clk)
begin
if(rising_edge(clk)) then
if condition1 then
result <= func(a+x);
elsif condition2 then
result <= func(a+y);
end if;
end if;
end process;

It's ambiguous exactly what hardware it will generate; there will be a mux driven by a combinational function of condition1 and condition2, but it isn't clear if the mux will be before the adder, before func, or after func. There is also an implicit clock enable generated because "result" isn't assigned from all branches.

Actually, it's not at all ambiguous. It is completely clear from the description.

First, the signal result is registered -- it is on the left-hand side of the assignments that are in the if rising_edge(clk) ... block.

Next, you've specified a mux for the assignment. That mux has three inputs, not two -- the third input is the previous value.

Last, the mux select is implemented with a priority encoder. condition1 and condition2 could both be true at the same time, but your code says that you want the assignment for the former to take precedence. Of course if neither are true then the previous value is assigned.

Whether the synthesis tool chooses to use the flip-flops' CE inputs or not depends on what makes the most sense to it. I've written code with a signal that I thought the synthesis tool would use as a clock enable, but nope. The logic on the D and CE inputs were not what I expected. But think about it. If the synthesis result is functionally correct, it doesn't matter how the logic is implemented. All that matters is if it works as intended (and meets timing).

That said: you are entirely correct when you write,

you quickly realize you have a LONG combinational path of a mux feeding an adder feeding a combinational "func".

Everyone writing any HDL should realize that the right-hand-sides of assignments really are bunches of combinational logic. And that the "if" statement is part of that logic.

If I have concerns that the large amount of combinatorial logic in my synchronous processes are not correct, sometimes I'll use VHDL variables and split that logic so it's visible in simulation. (Also it can make for shorter lines and more readable code.) It ends up being like your intermediate concurrent signal assignments, only they're within the process.

You can also see that there are two paths, a data path and a clock enable path. The clock enable path is short and the data path is long, which you won't easily see with the process version. You can also more easily see exactly where your registers are this way and know what paths may be a timing problem before synthesis.

I suppose it's worth doing the experiment to see what logic is created by the two idioms, and whether one or the other is faster. That all may depend on the fabric.

[ali_asadzadeh]

Today, these Little baby Dragons arrived to me at last!


What should I do with them!?
They are so Cute