Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
While reviewing the code that the FPGA group has produced, I saw
something that looks bad. It is not likely to affect the
functionality, but it is not good coding style and may use extra
resources.
They are using Verilog which is not my first HDL language and I am not
as familiar with it as I am VHDL. But because the case statement is
not fully specified the code below appears to me to produce more
complex logic than needed.
always @ (negedge rst_n or posedge clk) begin
if (!rst_n)begin
mask_wr <= 1'b0;
clear_wr <= 1'b0;
end
else begin
if (wr == 1'b1)begin
case (adr [2:1])
MASK: mask_wr <= 1'b1;
CLEAR: clear_wr <= 1'b1;
endcase
end
else begin
mask_wr <= 1'b0;
clear_wr <= 1'b0;
end
end
end
The real code is controlling 20 or so signals and is very large so this
is very simplified. At first I didn't notice the enclosing "always"
statement and thought it would produce a latch. Now I realize that it
will make enabled registers when what is really desired is just
decoders followed by registers. I guess in the grand scheme of things
this is not a big issue. But wouldn't it make a more streamlined
result to code the logic separate from the register? Then the logic
would just be decodes of the address bus and the control signal and the
register would not have separate enables.
Article: 105676"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1154099086.215982.7080@m79g2000cwm.googlegroups.com... > While reviewing the code that the FPGA group has produced, I saw > something that looks bad. It is not likely to affect the > functionality, but it is not good coding style and may use extra > resources. > > They are using Verilog which is not my first HDL language and I am not > as familiar with it as I am VHDL. But because the case statement is > not fully specified the code below appears to me to produce more > complex logic than needed. > > always @ (negedge rst_n or posedge clk) begin > if (!rst_n)begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > else begin > if (wr == 1'b1)begin > case (adr [2:1]) > MASK: mask_wr <= 1'b1; > CLEAR: clear_wr <= 1'b1; > endcase > end > else begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > end > end > > The real code is controlling 20 or so signals and is very large so this > is very simplified. At first I didn't notice the enclosing "always" > statement and thought it would produce a latch. Now I realize that it > will make enabled registers when what is really desired is just > decoders followed by registers. I guess in the grand scheme of things > this is not a big issue. But wouldn't it make a more streamlined > result to code the logic separate from the register? Then the logic > would just be decodes of the address bus and the control signal and the > register would not have separate enables. It may be cleaner to have simpler logic where the style mask_wr <= wr & adr[2:1]==MASK; is used for several declarations. This looks very similar to code I'm used to seeing where you could substitute the write strobes with the actual register write of the mask and clear registers in the case statement for and exclude the else. It may be the engineer used a common block and pared it down to produce just the strobes. Synthesizers tend to imply less about the type of flop - enabled, synchronous reset - from the code than they used to, usually ending up with a well-optimized result. Sometimes you have to kick the synthesizer in the @$$. I'd rewrite the always block if the code was something I became responsible for. It works fine, simulates fine, synthesizes fine; it's just us humans that are uncomfortable with the style. - John_HArticle: 105677
rickman wrote:
> always @ (negedge rst_n or posedge clk) begin
> if (!rst_n)begin
> mask_wr <= 1'b0;
> clear_wr <= 1'b0;
> end
> else begin
> if (wr == 1'b1)begin
> case (adr [2:1])
> MASK: mask_wr <= 1'b1;
> CLEAR: clear_wr <= 1'b1;
> endcase
> end
> else begin
> mask_wr <= 1'b0;
> clear_wr <= 1'b0;
> end
> end
> end
process(rst_n,clk)
begin
if (rst_n='0') then
mask_wr<='0';
clear_wr<='0';
elsif rising_edge(clk) then
if (wr='1') then
case adr(2 downto 1) is
when MASK => mask_wr<='1';
when CLEAR => clear_wr<='1';
when others => null;
end case;
else
mask_wr<='0';
clear_wr<='0';
end if;
end if;
end process;
(Translated manually without checking.)
I don't see anthything inefficient. 2 Flipflops with async reset.
Ralf
Article: 105678"RobertP." <r_p_u_d_l_i_k@poczta.onet.pl> wrote in message news:eaa39s$ccl$1@nemesis.news.tpi.pl... > Hello, > I have a design with two FPGAs (Xilinx Spartan3). Both use common clock, > and both can send data to the other one in a synchronous manner. Because > of possible clock skew, the critical seems to be meeting input hold time > requirements (setup is not a problem). This can be solved by adding > additional delay on the data path, and I wanted to use IOBDELAY element > for this purpose. > But I'm not sure how to calculate the hold time of the input flip-flop > when the IOBDELAY is added and a DCM is used. The datasheet specifies only > TPHDCM (IOBDELAY=NONE, DCM used) or TPHFD (IOBDELAY=IFD, DCM not used). > There is also TIOICKPD parameter (hold time at the IFF in respect to clock > on this flip-flop, and not on the global clock pin), but then I'm not sure > how to calculate the skew between IFF clock and clock on the input pin > (the DCM is used). > Any ideas how to approach this problem? > > -- > Regards > RobertP. If the clock period is long enough and the board-level clock skew is not too large, an easy solution is to use opposite edge clocking (out on falling edge, in on rising edge) between the devices. However you handle the clocking, the static timing report will tell you the external setup and hold times relative to the clock input pad. These numbers account for everything inside the device, inlcuding IBUFs, IBUFGs, BUFGs, IOBDELAYs, DCMs, etc. Just route the thing and let the tools give you the timing numbers. Then you go back to the data sheet and see if you can figure out where the numbers came from (if you insist). RobArticle: 105679
Ralf Hildebrandt wrote: > rickman wrote: > > > always @ (negedge rst_n or posedge clk) begin > > if (!rst_n)begin > > mask_wr <= 1'b0; > > clear_wr <= 1'b0; > > end > > else begin > > if (wr == 1'b1)begin > > case (adr [2:1]) > > MASK: mask_wr <= 1'b1; > > CLEAR: clear_wr <= 1'b1; > > endcase > > end > > else begin > > mask_wr <= 1'b0; > > clear_wr <= 1'b0; > > end > > end > > end > > process(rst_n,clk) > begin > if (rst_n='0') then > mask_wr<='0'; > clear_wr<='0'; > elsif rising_edge(clk) then > if (wr='1') then > case adr(2 downto 1) is > when MASK => mask_wr<='1'; > when CLEAR => clear_wr<='1'; > when others => null; > end case; > else > mask_wr<='0'; > clear_wr<='0'; > end if; > end if; > end process; > > (Translated manually without checking.) > > I don't see anthything inefficient. 2 Flipflops with async reset. Two FFs and four logic elements (x15 in the real circuit). You have to use a LUT to drive the D input and you have to use a LUT to drive the enable input. Of course you can feedback the output to the input and not use the clock enable, but that will also use more LUTs depending on if you have the extra inputs or not on the LUTs you are using. But this will be up to the tool and many times I see the tool generating logic to feed the clock enable. It is not a big deal. I tend to think of things like this when I code in an HDL just so I know my logic generation is lean. Originally I had not seen the enclosing always statement and was thinking it was generating a latch. Once I started looking at it I realize the latch was not an issue but thought about the extra logic being generated. I tend to separate my registers from my logic just to allow me to optimize this sort of thing.Article: 105680
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1154099086.215982.7080@m79g2000cwm.googlegroups.com... > While reviewing the code that the FPGA group has produced, I saw > something that looks bad. It is not likely to affect the > functionality, but it is not good coding style and may use extra > resources. > > They are using Verilog which is not my first HDL language and I am not > as familiar with it as I am VHDL. But because the case statement is > not fully specified the code below appears to me to produce more > complex logic than needed. > > always @ (negedge rst_n or posedge clk) begin > if (!rst_n)begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > else begin > if (wr == 1'b1)begin > case (adr [2:1]) > MASK: mask_wr <= 1'b1; > CLEAR: clear_wr <= 1'b1; > endcase > end > else begin > mask_wr <= 1'b0; > clear_wr <= 1'b0; > end > end > end > > The real code is controlling 20 or so signals and is very large so this > is very simplified. At first I didn't notice the enclosing "always" > statement and thought it would produce a latch. Now I realize that it > will make enabled registers when what is really desired is just > decoders followed by registers. I guess in the grand scheme of things > this is not a big issue. But wouldn't it make a more streamlined > result to code the logic separate from the register? Then the logic > would just be decodes of the address bus and the control signal and the > register would not have separate enables. > Rick - This looks fine to me. It's easy to read and will function correctly, plus the case statement and use of parameters make it easy to modify. Given what I've heard of your relationship with the FPGA group, I would not flag this if I were you. It would be nitpicking. RobArticle: 105681
rickman wrote:
>> process(rst_n,clk)
>> begin
>> if (rst_n='0') then
>> mask_wr<='0';
>> clear_wr<='0';
>> elsif rising_edge(clk) then
>> if (wr='1') then
>> case adr(2 downto 1) is
>> when MASK => mask_wr<='1';
>> when CLEAR => clear_wr<='1';
>> when others => null;
>> end case;
>> else
>> mask_wr<='0';
>> clear_wr<='0';
>> end if;
>> end if;
>> end process;
> Two FFs and four logic elements (x15 in the real circuit). You have to
> use a LUT to drive the D input and you have to use a LUT to drive the
> enable input. Of course you can feedback the output to the input and
> not use the clock enable, but that will also use more LUTs depending on
> if you have the extra inputs or not on the LUTs you are using.
I don't know your target, but I don't thinks a clock-enable will be
implemented. There will be a mux that selects ('1', '0' or the previous
value of the FFs) I guess.
If this is the desired functional behavior I don't see any option to
make it smaller. If there are don't care conditions there may be options.
There will be no difference between the way of coding this (two
processes for the FFs and the combinational logic). There will be only a
difference if you find some functional simplification of the problem.
Ralf
Article: 105682Hi All, I've put a new, a little more polished version of the fpgadbg (ver. 1.1) on the website http://www.ise.pw.edu.pl/~wzab/fpgadbg . The new version contains fpgadbg_uart - a wrapper allowing to debug via the serial UART interface. There is also a very simple demo, allowing to use fpgadbg with the Spartan 3 Starter Board. I hope someone will find it useful. -- Regards, Wojtek ZabolotnyArticle: 105683
"Wojciech Zabolotny" <wzab@mail.cern.ch> wrote in message news:Pine.LNX.4.58.0607281757360.3310@lxplus005.cern.ch... > Hi All, > I've put a new, a little more polished version of the fpgadbg (ver. 1.1) > on the website http://www.ise.pw.edu.pl/~wzab/fpgadbg . > The new version contains fpgadbg_uart - a wrapper allowing to debug via > the serial UART interface. > There is also a very simple demo, allowing to use fpgadbg with the Spartan > 3 Starter Board. > > I hope someone will find it useful. > -- > Regards, > Wojtek Zabolotny Wojtek - Thank you for the contribution. I don't have use for it right now, but I'll file your link away for possible future use. RobArticle: 105684
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:1154101628.534694.304340@s13g2000cwa.googlegroups.com... > Two FFs and four logic elements (x15 in the real circuit). You have to > use a LUT to drive the D input and you have to use a LUT to drive the > enable input. Of course you can feedback the output to the input and > not use the clock enable, but that will also use more LUTs depending on > if you have the extra inputs or not on the LUTs you are using. But > this will be up to the tool and many times I see the tool generating > logic to feed the clock enable. > > It is not a big deal. I tend to think of things like this when I code > in an HDL just so I know my logic generation is lean. Originally I had > not seen the enclosing always statement and was thinking it was > generating a latch. Once I started looking at it I realize the latch > was not an issue but thought about the extra logic being generated. I > tend to separate my registers from my logic just to allow me to > optimize this sort of thing. You're taking the code structure as a literal guide for synthesis. There will be two FFs and two LUTs without a clock enable. Synthesis typically knows what simple logic breaks down to and how to best implement it. If you go into the technology view of your synthesizer to look at one of the flops, expect to see only one LUT driving it, no clock enable involved.Article: 105685
Weng Tianxiang wrote:
> In the following statement:
> var := (var - 1) mod var_limit;
> var is not assigned any value before it is used. var_limit is a
> constant, of course.
> Anything is wrong?
No.
For simulation, the present value is used
to calculate and save the expression value.
For synthesis, this is infers a register to save
the value for the next process loop.
-- Mike Treseler
Article: 105686Decimation used not to work in MAC FIR until certain version. I believe it should have been fixed in v5.1. It might be that you are using an old core. /MikhailArticle: 105687
I read the whole thread and no one recommended "The Art Of Electronics" by Horowitz and Hill??Article: 105688
Hi Mike, Thank you for your response. Now what is the first value after system asynchronous reset for first loop? Thank you. Weng Mike Treseler wrote: > Weng Tianxiang wrote: > > > In the following statement: > > var := (var - 1) mod var_limit; > > var is not assigned any value before it is used. var_limit is a > > constant, of course. > > Anything is wrong? > > No. > For simulation, the present value is used > to calculate and save the expression value. > For synthesis, this is infers a register to save > the value for the next process loop. > > -- Mike TreselerArticle: 105689
BobG wrote:
> I read the whole thread and no one recommended "The Art Of Electronics"
> by Horowitz and Hill??
That's more of an electronics book than an RTL book.
-- Mike Treseler
Article: 105690Hi, Synplify gives you a warning, and not an error. It just tells you that it is not able to extract the timing behavior of the IP that you declared as black box. Here, it doesn't read the netlists. This is not really a problem if your design is not timing critical. Normally, Synplify_pro can read back the different edf and edn netlists. You have to add an add_file -edif "edif_file_name" to your *.prj project file and delete the attributes you added in your VHDL code. However, when generating a FIFO, coregen generates edn files, but also an *.ngc file. This file should be converted into an *.ndf file (using: ngc2edif *.ngc) and then added to the Synplify_pro project if you want it to extract the timing behavior of the IP. Remember that Synplify then optimizes the logic which is around the IP (in the modules written in VHDL/Verilog), but it won't re-optimize the netlist itself unless you ask it to do so with the syn_macro attribute. One last thing: why are you using coregen to generate FIFOs ? There are many VHDL/Verilog generic FIFO/RAM/ROM models available over the internet that you could use much more easily ! Make a search over the posts in this group, you'll have some examples. Regards, Arnaud pauljbennett@gmail.com wrote: > Hey all, > > Thanx in advance for any help. I've got a few FIFO cores that I > created in Xilinx Core Generator. I instantiated them in my top level > VHDL, and added the syplicity blackbox declarations after the component > declarations, as specified in the various Xilinx/Synplicity documents: > > -- Synplicity black box declaration > attribute syn_black_box : boolean; > attribute syn_black_box of serial_fifo : component is true; > > I added the top level vhdl, and the Xilinx generated EDIF netlists > to my synplicity project... when I run it I get: > > warning ID MT246 : Blackbox output_fifo_fifo_generator_v2_3_xst_1 is > missing a user supplied timing model. > > Now, from everything I read in the various PRF documents, the purpose > of adding the EDIF files to the synplicity project is to generate said > timing? No? Anyone know why synplicity is complaining here? Thanx.Article: 105691
Weng Tianxiang wrote:
> Hi Mike,
> Thank you for your response.
> Now what is the first value after system asynchronous reset for first
> loop?
Whatever the reset code says it is.
If there is no reset code, it might be a 'U'.
Check your simulation waveforms for exact answers.
-- Mike Treseler
Article: 105692Arnaud, My only concern with recommending any generic FIFO IP is that you get what you pay for: a FIFO is one element that I have seen done wrong over and over and.... If you use coregen, then you do not have to worry. Austin Arnaud wrote: > Hi, > > Synplify gives you a warning, and not an error. It just tells you that > it is not able to extract the timing behavior of the IP that you > declared as black box. Here, it doesn't read the netlists. This is not > really a problem if your design is not timing critical. > > Normally, Synplify_pro can read back the different edf and edn > netlists. You have to add an > add_file -edif "edif_file_name" > to your *.prj project file and delete the attributes you added in your > VHDL code. > > However, when generating a FIFO, coregen generates edn files, but also > an *.ngc file. This file should be converted into an *.ndf file (using: > ngc2edif *.ngc) and then added to the Synplify_pro project if you want > it to extract the timing behavior of the IP. > > Remember that Synplify then optimizes the logic which is around the IP > (in the modules written in VHDL/Verilog), but it won't re-optimize the > netlist itself unless you ask it to do so with the syn_macro attribute. > > One last thing: why are you using coregen to generate FIFOs ? There are > many VHDL/Verilog generic FIFO/RAM/ROM models available over the > internet that you could use much more easily ! Make a search over the > posts in this group, you'll have some examples. > > Regards, > > Arnaud > > pauljbennett@gmail.com wrote: >> Hey all, >> >> Thanx in advance for any help. I've got a few FIFO cores that I >> created in Xilinx Core Generator. I instantiated them in my top level >> VHDL, and added the syplicity blackbox declarations after the component >> declarations, as specified in the various Xilinx/Synplicity documents: >> >> -- Synplicity black box declaration >> attribute syn_black_box : boolean; >> attribute syn_black_box of serial_fifo : component is true; >> >> I added the top level vhdl, and the Xilinx generated EDIF netlists >> to my synplicity project... when I run it I get: >> >> warning ID MT246 : Blackbox output_fifo_fifo_generator_v2_3_xst_1 is >> missing a user supplied timing model. >> >> Now, from everything I read in the various PRF documents, the purpose >> of adding the EDIF files to the synplicity project is to generate said >> timing? No? Anyone know why synplicity is complaining here? Thanx. >Article: 105693
As a complete newbie to Verilog and FPGA's, this statement in Xilinx's documentation has me confused. How do I instantiate library objects that are "inferred rather than instantiated" in my project using HDL? I can add an instance with a schematic but I don't know what this inference means to include this in my Verilog files. Thanks!Article: 105694
Nevo wrote: > As a complete newbie to Verilog and FPGA's, this statement in Xilinx's > documentation has me confused. > > How do I instantiate library objects that are "inferred rather than > instantiated" in my project using HDL? I can add an instance with a > schematic but I don't know what this inference means to include this in > my Verilog files. > > Thanks! Let me try this again in English... :) How do I include library parts that are "inferred rather than instantiated" in a project when I'm creating the project in Verilog? For instance, if I want a D4_16E (a 4-bit one-of-sixteen decoder) in my project, how would I do that?Article: 105695
It is a matter of luck. Most modern chipsets don't have 5V used in driving the PCI bus. Very often it is 3.3V so you won't see an issue until someone plugs in an old card, or uses an old motherboard, that maybe does drive something towards 5V. Putting bus switches in the way technically fails the PCI spec but we have not had an issue reported with our FPGA development boards to do with having bus switches there. I don't think any other manufacturers have had either that I have heard of. If you do use this approach ensure the bus switch used does not have a diode to Vcc. John Adair Enterpoint Ltd. yy wrote: > Hi, > I have a Working Universal PCI Evaluation Kit (Spartan3) without any > Bus Switches/resistors etc. The package name is 'TruePCI', and it works > fine with a motherboard that have 5V slots. The bank VCCO of Spartan 3 > is wired to +3.3V, many have said that bus switches are needed in order > to connect Spartan 3 to PCI? But then this board seems to work pretty > well, Any ideas? BTW, what i'm building is a specialized pci board. > > Thanks.Article: 105696
Nevo wrote: > Nevo wrote: > > As a complete newbie to Verilog and FPGA's, this statement in Xilinx's > > documentation has me confused. > > > > How do I instantiate library objects that are "inferred rather than > > instantiated" in my project using HDL? I can add an instance with a > > schematic but I don't know what this inference means to include this in > > my Verilog files. > > > > Thanks! > > Let me try this again in English... :) > > How do I include library parts that are "inferred rather than > instantiated" in a project when I'm creating the project in Verilog? > For instance, if I want a D4_16E (a 4-bit one-of-sixteen decoder) in my > project, how would I do that? Do you have a good verilog language reference in print form? If not, you should probably invest in one, as the majority of the online ones are incomplete. I've used this one: http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/Verilog/Verilog.htm a couple times. I think this page: http://www.doulos.com/knowhow/verilog_designers_guide/a_design_hierarchy/ will answer your question, but doesn't cover the topic in much depth. Also, don't post verilog questions in comp.arch.fpga unless the are directly related to synthesis on an FPGA. While most of the people here know verilog and/or VHDL, you should still go to comp.lang.verilog if it's nothing but a simple language question. Some people get very hostile if you post in the wrong group. Most just ignore you.Article: 105697
You can assignee an initial value when a variable or signal is
declared, e.g.,
signal mysig: std_logic := '0';
This will be the initial value when simulation starts. According to
VHDL LRM, if there is no initial value, the first value defined in the
data type will be used. Since std_logic is defined as ('U', 'X', '0',
...) in 1164 package. The 'U' value (for uninitialized) will be the
default value.
Since the initial value cannot always be synthesized, this approach
should not be used in synthesis. It is better to use an explicit reset
mechanism to initialize a sequential circuit.
Mike G.
Weng Tianxiang wrote:
> Hi Mike,
> Thank you for your response.
> Now what is the first value after system asynchronous reset for first
> loop?
>
> Thank you.
>
> Weng
>
> Mike Treseler wrote:
> > Weng Tianxiang wrote:
> >
> > > In the following statement:
> > > var := (var - 1) mod var_limit;
> > > var is not assigned any value before it is used. var_limit is a
> > > constant, of course.
> > > Anything is wrong?
> >
> > No.
> > For simulation, the present value is used
> > to calculate and save the expression value.
> > For synthesis, this is infers a register to save
> > the value for the next process loop.
> >
> > -- Mike Treseler
Article: 105698All information is available either in device user guide or from the ISE tools (PACE, FPGA_EDITOR, etc). ADEPT presents these information in an easier-to-read way (or so I hope) ;) HTH, Jim ba@jb.man.ac.uk wrote: > Hi Jim, > > Jim Wu wrote: > > ADEPT will answer most (if not all) of your questions. Check it out at > > I would love to use it but I am running ISE 8.1.03i on > linux ( fedora core 4). If I can't get an answer, I will > install on Windows and try it. > > Are Xilinx hiding the information so you can give > away the tool with the answers for free? How did > you get the knowledge? > > BryanArticle: 105699
On 2006-07-28, Nevo <nevo_n@hotmail.com> wrote: > > How do I instantiate library objects that are "inferred rather than > instantiated" in my project using HDL? You use an HDL template that the synthesizer recognizes. If you Google xst.pdf you will find the templates you need. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z