Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 105675

Article: 105675
Subject: Verilog case statements
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 28 Jul 2006 08:04:46 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Verilog case statements
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 28 Jul 2006 15:22:18 GMT
Links: << >>  << T >>  << A >>
"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_H 



Article: 105677
Subject: Re: Verilog case statements
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Fri, 28 Jul 2006 17:35:40 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: IOBDELAY and DCM
From: "RobJ" <rob@abc.net>
Date: Fri, 28 Jul 2006 15:40:38 GMT
Links: << >>  << T >>  << A >>
"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).

Rob 



Article: 105679
Subject: Re: Verilog case statements
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 28 Jul 2006 08:47:08 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: Verilog case statements
From: "RobJ" <rob@abc.net>
Date: Fri, 28 Jul 2006 15:48:10 GMT
Links: << >>  << T >>  << A >>
"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.

Rob 



Article: 105681
Subject: Re: Verilog case statements
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Fri, 28 Jul 2006 18:02:57 +0200
Links: << >>  << T >>  << A >>
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: 105682
Subject: New version of fpgadbg available - with serial port support
From: Wojciech Zabolotny <wzab@mail.cern.ch>
Date: Fri, 28 Jul 2006 18:10:14 +0200
Links: << >>  << T >>  << A >>
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

Article: 105683
Subject: Re: New version of fpgadbg available - with serial port support
From: "RobJ" <rob@abc.net>
Date: Fri, 28 Jul 2006 16:25:45 GMT
Links: << >>  << T >>  << A >>
"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.

Rob 



Article: 105684
Subject: Re: Verilog case statements
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 28 Jul 2006 16:30:18 GMT
Links: << >>  << T >>  << A >>
"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
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 28 Jul 2006 09:30:18 -0700
Links: << >>  << T >>  << A >>
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: 105686
Subject: Re: Does MAC FIR filter need special care?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 28 Jul 2006 13:25:48 -0400
Links: << >>  << T >>  << A >>
Decimation 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.

/Mikhail



Article: 105687
Subject: Re: Hardware book like "Code Complete"?
From: "BobG" <bobgardner@aol.com>
Date: 28 Jul 2006 10:34:59 -0700
Links: << >>  << T >>  << A >>
I read the whole thread and no one recommended "The Art Of Electronics"
by Horowitz and Hill??


Article: 105688
Subject: Re: Hardware book like "Code Complete"?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 28 Jul 2006 10:46:33 -0700
Links: << >>  << T >>  << A >>
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: 105689
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 28 Jul 2006 11:33:25 -0700
Links: << >>  << T >>  << A >>
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: 105690
Subject: Re: Xilinx Corgen & Synplicity... Anyone? Help?
From: "Arnaud" <arivaton@gmail.com>
Date: 28 Jul 2006 11:41:10 -0700
Links: << >>  << T >>  << A >>
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: 105691
Subject: Re: Hardware book like "Code Complete"?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 28 Jul 2006 11:42:03 -0700
Links: << >>  << T >>  << A >>
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: 105692
Subject: Re: Xilinx Corgen & Synplicity... Anyone? Help?
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 28 Jul 2006 12:06:48 -0700
Links: << >>  << T >>  << A >>
Arnaud,

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
Subject: "This design element is inferred rather than instantiated" (newbie)
From: "Nevo" <nevo_n@hotmail.com>
Date: 28 Jul 2006 12:15:40 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: "This design element is inferred rather than instantiated" (newbie)
From: "Nevo" <nevo_n@hotmail.com>
Date: 28 Jul 2006 12:22:36 -0700
Links: << >>  << T >>  << A >>

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
Subject: Re: Spartan3 5V PCI
From: "John Adair" <g1@enterpoint.co.uk>
Date: 28 Jul 2006 12:49:18 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: "This design element is inferred rather than instantiated" (newbie)
From: "Brian McFarland" <brian.mcf1985@gmail.com>
Date: 28 Jul 2006 12:51:32 -0700
Links: << >>  << T >>  << A >>

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
Subject: Re: Hardware book like "Code Complete"?
From: mikegurche@yahoo.com
Date: 28 Jul 2006 12:55:15 -0700
Links: << >>  << T >>  << A >>
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: 105698
Subject: Re: 4VSX35 LOC placements?
From: "Jim Wu" <jimwu88NOOOSPAM@yahoo.com>
Date: 28 Jul 2006 13:18:07 -0700
Links: << >>  << T >>  << A >>
All 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?
> 
> Bryan


Article: 105699
Subject: Re: "This design element is inferred rather than instantiated" (newbie)
From: Ben Jackson <ben@ben.com>
Date: Fri, 28 Jul 2006 15:30:55 -0500
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search