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 119500

Article: 119500
Subject: Does FPGA need CPU for processing a packet/frame
From: NewToFPGA <hetzme@yahoo.com>
Date: 21 May 2007 09:56:11 -0700
Links: << >>  << T >>  << A >>
I have an FPGA for taking a packet/frame/data from one port and
transfer it to a different port based on the header information (say a
Layer 2 Switch). Does it involve the CPU for for processing this frame
at all?


Article: 119501
Subject: Does FPGA need CPU for processing a packet/frame
From: NewToFPGA <hetzme@yahoo.com>
Date: 21 May 2007 09:56:14 -0700
Links: << >>  << T >>  << A >>
I would like to know if an FPGA needs CPU for processing a packet/
frame that it receives.

For example an FPGA is capable of processing a frame based on its
destination Address (similar to layer 2 ethernet device). Does the
FPGA takes help of CPU in actually moving the frame from one port to
another port? Or does it do on its own.

My understanding of an FPGA is that during the start up time we need
to register the FPGA with the processor. We also register the actions
that we perform, interrupts. We configure the FPGA to do specific job
during the FPGA initialization. After that FPGA does not use CPU for
any of the internal work it has to do. It can talk to the CPU in case
of exceptions, so that CPU can look at the packet and do more
application level processing.

Thanks.


Article: 119502
Subject: Re: Does FPGA need CPU for processing a packet/frame
From: "John_H" <newsgroup@johnhandwork.com>
Date: Mon, 21 May 2007 10:06:43 -0700
Links: << >>  << T >>  << A >>
"NewToFPGA" <hetzme@yahoo.com> wrote in message 
news:1179765788.179147.285750@y2g2000prf.googlegroups.com...
>I would like to know if an FPGA needs CPU for processing a packet/
> frame that it receives.
>
> For example an FPGA is capable of processing a frame based on its
> destination Address (similar to layer 2 ethernet device). Does the
> FPGA takes help of CPU in actually moving the frame from one port to
> another port? Or does it do on its own.
>
> My understanding of an FPGA is that during the start up time we need
> to register the FPGA with the processor. We also register the actions
> that we perform, interrupts. We configure the FPGA to do specific job
> during the FPGA initialization. After that FPGA does not use CPU for
> any of the internal work it has to do. It can talk to the CPU in case
> of exceptions, so that CPU can look at the packet and do more
> application level processing.
>
> Thanks.


An FPGA can do what the designer dictates.  If the FPGA is designed to 
handle packets, it will do so.  The FPGA can contain a processor within 
itself to handle protocol stacks that are typically too complex to handle in 
a simple hardware state machine.  If the FPGA is designed to handle the 
packet/frame then the external CPU isn't needed.  If the FPGA is designed to 
have the CPU process the packet/frame then the CPU is needed.

The need to register the FPGA with the processor and the actions and 
interrupts thereof are application specific.  The system is designed with 
these needs so the FPGA is designed to support them.

If you're designing an FPGA limited to layer-2 processing, you probably 
don't need to design an internal or external CPU control for your needs. 
The buffers and address processing can all be internal to the FPGA. 



Article: 119503
Subject: Re: Does FPGA need CPU for processing a packet/frame
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 21 May 2007 10:13:53 -0700
Links: << >>  << T >>  << A >>
NewToFPGA wrote:
> I would like to know if an FPGA needs CPU for processing a packet/
> frame that it receives.

No, but it is common that some CPU
collects packet data and statistics for presentation
to some user interface.

> For example an FPGA is capable of processing a frame based on its
> destination Address (similar to layer 2 ethernet device). Does the
> FPGA takes help of CPU in actually moving the frame from one port to
> another port? Or does it do on its own.

If the CPU were fast enough to
to handle the line rate, I wouldn't need
an FPGA in the first place. If I need
an FPGA, I probably need it for all of
the packet processing.

> My understanding of an FPGA is that during the start up time we need
> to register the FPGA with the processor.

The CPU clock and the line clock are
usually different. I write a design entity
for each clock domain with explicit synchronization
between the entities using handshaking, fifos, sampling etc.

> We configure the FPGA to do specific job
> during the FPGA initialization. After that FPGA does not use CPU for
> any of the internal work it has to do. It can talk to the CPU in case
> of exceptions, so that CPU can look at the packet and do more
> application level processing.

That sounds reasonable.

   -- Mike Treseler

Article: 119504
Subject: Re: Does FPGA need CPU for processing a packet/frame
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 21 May 2007 10:19:38 -0700
Links: << >>  << T >>  << A >>
You can implement a general purpose CPU inside an FPGA, therefore you
can do anything inside an FPGA that a CPU can do.

For packet inspection implementing a general purpose CPU inside an
FPGA
might be a good way to go, or it might not. I don't know.
(Someone once said: "special purpose hardware is always better than
general
purpose hardware except for general cases ;-)

Kolja


On May 21, 6:43 pm, NewToFPGA <het...@yahoo.com> wrote:
> I would like to know if an FPGA needs CPU for processing a packet/
> frame that it receives.
>
> For example an FPGA is capable of processing a frame based on its
> destination Address (similar to layer 2 ethernet device). Does the
> FPGA takes help of CPU in actually moving the frame from one port to
> another port? Or does it do on its own.
>
> My understanding of an FPGA is that during the start up time we need
> to register the FPGA with the processor. We also register the actions
> that we perform, interrupts. We configure the FPGA to do specific job
> during the FPGA initialization. After that FPGA does not use CPU for
> any of the internal work it has to do. It can talk to the CPU in case
> of exceptions, so that CPU can look at the packet and do more
> application level processing.


Article: 119505
Subject: Re: VHDL newbie: building sequential circuits with basic gates
From: Andy <jonesandy@comcast.net>
Date: 21 May 2007 10:48:22 -0700
Links: << >>  << T >>  << A >>
On May 21, 11:42 am, Jim Lewis <j...@synthworks.com> wrote:
> KJ,
>
> > Another example of such a difference between when a particular type is good
> > to use or not would be between the use of type 'unsigned' or type 'natural'
> > when creating a counter (or adder).  In the hands of the more skilled
> > designer, type 'natural' is usually preferred; in the hands of the less
> > skilled the use of type 'natural' can cause problems because signals of type
> > natural will always magically initialize to 0 in simulation.
>
> Do you find that you are getting good usage of carry out in
> place of zero detection with natural?
>
> For example, with unsigned, I can explicitly code the carry out
> by adding one bit to my decrement resource (variable Count17)
> as shown below.  As a result, the zero detect is implemented as
> a single carry/borrow cell (one LUT) for any size of counter.
> If you do a test, make sure to use at least 16 bits so you can
> notice the difference.
>
>    signal EndDetect : std_logic ;
>    signal Count16Reg : unsigned(15 downto 0) ;
> ...
>
> process (...)
>    variable count17 : unsigned(16 downto 0) ;
> begin
> ...
>    Count17     := Count17 - 1 ;
>    EndDetect   <= Count17(16) ; -- carry bit.
>    Count16Reg  <= Count17 (15 downto 0) ;
> ...
>
> Now if the current generation of synthesis tools can always
> extract this information from the following, then there is no
> point in working to create the result with unsigned.
>
>    signal EndDetect : std_logic ;
>    signal CountReg : natural range 0 to 2**16 - 1 ;
>
> ...
>    CountReg <= CountReg - 1 ;
> ...
>    EndDetect <= '1' when CountReg = 0 else '0' ;
>
> WRT initialzation, you will always find that in gate sims,
> however, it is not a nice time to find it if a rookie forgets
> to reset many registers.
>
> Cheers,
> Jim

Here's how I do it with natural types:

signal count : natural range 0 to 2**numbits - 1;

...

if count - 1 < 0 then
  do_end_of_count_stuff_here;
else
  count <= count - 1;
end if;

The important thing to remember is integer expressions are independent
on the "width" of the operands, and are always 32 bit signed. The
reduction (and bounds checking) is done only upon assignment to a
constrained subtype of integer. Thus even though count cannot be less
than zero, count - 1, as an integer expression can be. DO NOT TRY THIS
WITH UNSIGNED!

This also works for 2**n-1 bit rollovers in up counters.

The synthesis tools recognize the common expression and share the
adder between them, adding an extra bit for the sign only in the
comparison, not in storage. More specifically, the synthesis tools
discard all the extra bits from the 32 bit expression except for the
result and the sign.


Andy


Article: 119506
Subject: Re: Timing not met but working on board
From: Andy <jonesandy@comcast.net>
Date: 21 May 2007 10:59:12 -0700
Links: << >>  << T >>  << A >>
On May 21, 6:20 am, "KJ" <kkjenni...@sbcglobal.net> wrote:
> "J.Ram" <jrgod...@gmail.com> wrote in message
>
> news:1179737574.032115.244360@a26g2000pre.googlegroups.com...
>
> > Hi all,
> > I developed a design in which i need a master clock of 90Mhz, so
> > during synthesis max. freq obtained is 56Mhz and  timing is met for
> > global clock of 50Mhz, but timing are not met for 90Mhz.
> > but design is working on board for 90Mhz clcock.
> > In design all lower level module are working above 100 Mhz, but in top
> > module after integarting sub blocks it works around 56 Mhz in
> > synthesis and working at 90Mhz on board.
> > so please tell me what is wrong with this design.
> > Regards
> > J.Ram
>
> What is wrong is your expectation that based on a sample of one board that
> works at 90 MHz, that all boards over all rated temperature conditions over
> all possible input conditions will also work at that speed.
>
> It's not at all unusual to expect that a single board in a lab environment
> might happen to work at ~50% over the speed computed by the timing analyzer.
> Try building thousands of such boards and put them in the extreme rated
> temperature conditions and give them the most stressful input pattern and
> see how many of those boards still work.  What you'll likely find is a lot
> of fallout...but again you might have a few survivors.
>
> KJ

KJ nailed it.

Andy


Article: 119507
Subject: Re: VHDL newbie: building sequential circuits with basic gates
From: Jim Lewis <jim@synthworks.com>
Date: Mon, 21 May 2007 11:50:08 -0700
Links: << >>  << T >>  << A >>
Andy,
> Here's how I do it with natural types:
> 
> signal count : natural range 0 to 2**numbits - 1;
> 
> ...
> 
> if count - 1 < 0 then
>   do_end_of_count_stuff_here;
> else
>   count <= count - 1;
> end if;
> 
> The important thing to remember is integer expressions are independent
> on the "width" of the operands, and are always 32 bit signed. The
> reduction (and bounds checking) is done only upon assignment to a
> constrained subtype of integer. Thus even though count cannot be less
> than zero, count - 1, as an integer expression can be. DO NOT TRY THIS
> WITH UNSIGNED!
> 
> This also works for 2**n-1 bit rollovers in up counters.
> 
> The synthesis tools recognize the common expression and share the
> adder between them, adding an extra bit for the sign only in the
> comparison, not in storage. More specifically, the synthesis tools
> discard all the extra bits from the 32 bit expression except for the
> result and the sign.
> 
> 
> Andy
> 

Which tools have you verified that the synthesis tools give
you a good implementation?

Cheers,
Jim

Article: 119508
Subject: Re: VHDL newbie: building sequential circuits with basic gates
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 21 May 2007 12:01:50 -0700
Links: << >>  << T >>  << A >>
Andy wrote:

> This also works for 2**n-1 bit rollovers in up counters.

Yes.
For a related rollover example using unsigned,
see the carry chain map for the
"Clk Enabled Counters" example here:

http://home.comcast.net/~mike_treseler/

        -- Mike Treseler

Article: 119509
Subject: Re: How to insert tab in Write() function in VHDL
From: Gabor <gabor@alacron.com>
Date: 21 May 2007 12:17:01 -0700
Links: << >>  << T >>  << A >>
On May 20, 5:51 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Weng Tianxiang wrote:
> > Hi,
> > I want to insert tab in write() function in VHDL.
>
> (snip)
>
> >    type character is (
> >            nul, soh, stx, etx, eot, enq, ack, bel,
> >            bs,  ht,  lf,  vt,  ff,  cr,  so,  si,
> >            dle, dc1, dc2, dc3, dc4, nak, syn, etb,
> >            can, em,  sub, esc, fsp, gsp, rsp, usp,
>
> >            ' ', '!', '"', '#', '$', '%', '&', ''',
> >            '(', ')', '*', '+', ',', '-', '.', '/',
> >            '0', '1', '2', '3', '4', '5', '6', '7',
> >            '8', '9', ':', ';', '<', '=', '>', '?',
> > I want to know which one is tabulator (tab).
>
> ht is horizontal tab, vt is vertical tab.  There are terminals
> that know what to do with one or both of those.
>
> -- glen


You can see a list of all of these abbreviations at:

http://www.asciitable.com/


Article: 119510
Subject: ModelSim version upgrade problem from 6.1c to 6.2c
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: 21 May 2007 12:29:31 -0700
Links: << >>  << T >>  << A >>
Hi,
When my ModelSim version is upgraded from 6.1c to 6.2c, a new problem
happens:

When opening wave.do file, either created by 6.1c version or 6.2c
version, the following error information would appear:

# WLF Error: Bad initial WLF parcel. WLF file is corrupt.
# Cannot open file: C:/Weng/Simulation/CITO2/wave.do

It means I cannot normally use 6.2c version of ModelSim, because
complex waveform waveforms patters can be saved, but it cannot be
reopened.

Is there a way to resolve the problem?

Thank you.

Weng


Article: 119511
Subject: How to copy hex data from Quartus vwf file to text?
From: Harold <harold@hallikainen.com>
Date: 21 May 2007 13:05:02 -0700
Links: << >>  << T >>  << A >>
I'm just getting started with Quartus II v7.0. I have a test vwf file
for some existing vhdl. I'd like to copy the 128 bit hex values from
the vwf to a text file for my documentation. I can't seem to find how
to do that in the documentation, though it is probably buried in there
somewhere. Can anyone give a clue as to how to do this?

THANKS!

Harold


Article: 119512
Subject: Re: UART Receiver Parity Check
From: Eric Smith <eric@brouhaha.com>
Date: 21 May 2007 13:28:48 -0700
Links: << >>  << T >>  << A >>
Anson.Stuggart@gmail.com writes:
> bit with its own parity bit which is calculated using XOR of its data
> byte, RxReg(8 downto 0). My statement below is giving me a full byte
> delay because my control statements for the parity check. I think it's
> because of the process statement, but that's all I can think of now.
> 
> can someone let me know how to fix this?

The usual way to generate parity in a UART is to do it one bit at a
time, rather than all in parallel.  Since a UART is already shifting
the bits serially, this reduces the parity computation to a single
XOR gate and a single D FF.

Once per character (e.g., during the start bit), init the FF state
(value depending on whether you want even or odd parity).


Article: 119513
Subject: Re: Timing not met but working on board
From: Eric Smith <eric@brouhaha.com>
Date: 21 May 2007 13:30:45 -0700
Links: << >>  << T >>  << A >>
"J.Ram" wrote:
> I developed a design in which i need a master clock of 90Mhz, so
> during synthesis max. freq obtained is 56Mhz and  timing is met for
> global clock of 50Mhz, but timing are not met for 90Mhz.
> but design is working on board for 90Mhz clcock.
[...]
> so please tell me what is wrong with this design.

What is wrong is that you are running the part out of spec.
It might work fine on some particular chips at room temperature,
and fail on other chips or at elevated temperatures.

If you modify the design to meet timing, then it will work on
all chips over the rated temperature range.

Article: 119514
Subject: Re: Timing not met but working on board
From: Peter Alfke <peter@xilinx.com>
Date: 21 May 2007 14:28:24 -0700
Links: << >>  << T >>  << A >>
We all agree that it would be irresponsible to release a design that
does not meet timing specifications, and that the successful operation
of one board at a higher frequency really has no significance.
But you might want to explore WHY your timing analysis claims that the
design fails at such a low frequency.
Where are the >18 ns between clock edges, responsible for the 56 MHz
limit? Maybe it's easy to fix.
Peter Alfke

On May 21, 1:30 pm, Eric Smith <e...@brouhaha.com> wrote:
> "J.Ram" wrote:
> > I developed a design in which i need a master clock of 90Mhz, so
> > during synthesis max. freq obtained is 56Mhz and  timing is met for
> > global clock of 50Mhz, but timing are not met for 90Mhz.
> > but design is working on board for 90Mhz clcock.
> [...]
> > so please tell me what is wrong with this design.
>
> What is wrong is that you are running the part out of spec.
> It might work fine on some particular chips at room temperature,
> and fail on other chips or at elevated temperatures.
>
> If you modify the design to meet timing, then it will work on
> all chips over the rated temperature range.



Article: 119515
Subject: Atmel release Metal Programmable Cell Fabric uC ARM9
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 22 May 2007 09:40:24 +1200
Links: << >>  << T >>  << A >>

http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=CAP9_5_21.html
Atmel have done mask-metal flows for many years, this seems a 
simple/logical coupling with their exisiting CPU+Peripheral devices.

NRE costs start at $150K, which I think is not bad compared with the
other 'specific flow' FPGA NREs.

Anyone seen the NRE figures for the ST Spear series ?

AT91CAP9-DK sounds interesting, no mention of whose FPGA is used for
the development pathway ?

-jg


Article: 119516
Subject: Re: ModelSim version upgrade problem from 6.1c to 6.2c
From: "HT-Lab" <hans64@ht-lab.com>
Date: Mon, 21 May 2007 21:55:52 GMT
Links: << >>  << T >>  << A >>

"Weng Tianxiang" <wtxwtx@gmail.com> wrote in message 
news:1179775771.504358.102620@y18g2000prd.googlegroups.com...
> Hi,
> When my ModelSim version is upgraded from 6.1c to 6.2c, a new problem
> happens:
>
> When opening wave.do file, either created by 6.1c version or 6.2c
> version, the following error information would appear:
>
> # WLF Error: Bad initial WLF parcel. WLF file is corrupt.
> # Cannot open file: C:/Weng/Simulation/CITO2/wave.do
>
> It means I cannot normally use 6.2c version of ModelSim, because
> complex waveform waveforms patters can be saved, but it cannot be
> reopened.
>
> Is there a way to resolve the problem?

Try 6.3?,

pass the wlf to Mentor and ask them to look into it and provide a 
workaround,

or convert the 6.1c WLF to VCD (wlf2vcd) and back to WLF (vcd2wlf) in 6.2c,

Hans
www.ht-lab.com


>
> Thank you.
>
> Weng
> 



Article: 119517
Subject: Re: Atmel release Metal Programmable Cell Fabric uC ARM9
From: Antti <Antti.Lukats@googlemail.com>
Date: 21 May 2007 14:56:52 -0700
Links: << >>  << T >>  << A >>

Jim Granville schrieb:
> http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=CAP9_5_21.html
> Atmel have done mask-metal flows for many years, this seems a
> simple/logical coupling with their exisiting CPU+Peripheral devices.
>
> NRE costs start at $150K, which I think is not bad compared with the
> other 'specific flow' FPGA NREs.
>
> Anyone seen the NRE figures for the ST Spear series ?
>
> AT91CAP9-DK sounds interesting, no mention of whose FPGA is used for
> the development pathway ?
>
> -jg
I think the spear NRE is less then 150K
but dont recall so exactly

Antti


Article: 119518
Subject: Re: Atmel release Metal Programmable Cell Fabric uC ARM9
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Tue, 22 May 2007 09:58:07 +1200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> 
> http://www.atmel.com/dyn/corporate/view_detail.asp?FileName=CAP9_5_21.html
> Atmel have done mask-metal flows for many years, this seems a 
> simple/logical coupling with their exisiting CPU+Peripheral devices.
> 
> NRE costs start at $150K, which I think is not bad compared with the
> other 'specific flow' FPGA NREs.
> 
> Anyone seen the NRE figures for the ST Spear series ?
> 
> AT91CAP9-DK sounds interesting, no mention of whose FPGA is used for
> the development pathway ?

A manual search finds this - the 200 page Development Kit user manual

http://www.atmel.com/dyn/general/tech_doc.asp?doc_id=11144

FPGA Emulation/development device is : (Altera Stratix-II EP2S90F1020C5)

-jg


Article: 119519
Subject: Re: EDK 8.1i to EDK 9.1i UCF file errors
From: Nju Njoroge <njoroge@stanford.edu>
Date: 21 May 2007 15:45:27 -0700
Links: << >>  << T >>  << A >>
On May 20, 10:26 am, Joseph Samson <jsam...@the-company-name.com>
wrote:
> Nju Njorogewrote:
> > Hello,
>
> > In our *working* EDK 8.1i project, we locked aDCMin the following
> > manner in the UCF file (located in <proj_dir>/data/system.ucf):
>
>   [snip]...
>
> comment out theDCMLOC in your .ucf file, then run place and route.
> Open the design in FPGA Editor, find theDCMand look at the instance
> name. Now uncomment theDCMLOC and substitute the instance name that
> ISE 9.1i assigned. Rerun the place and route.
Great suggestion. I tried it and this is the name it uses: dcm_sys/
dcm_sys/Using_Virtex.DCM_INST

For some reason, the new tools appended a prefix "Using_Virtex" to the
DCM_INST.


Article: 119520
Subject: Xilinx doesn't detect setup/hold violations on synchronous reset
From: Frai <maybetooparanoid@gmail.com>
Date: 21 May 2007 16:59:37 -0700
Links: << >>  << T >>  << A >>
Hi all,

I am facing some problems with Xilinx ISE 8.2 not taking into account
synchronous reset setup/hold violations on FFs. My code looks like
this:

Inst_my_dcm_a: my_dcm
	PORT MAP(
		CLKIN_IN => dsp_clk_pad_a,
		RST_IN => "not"(nreset),
		CLKDV_OUT => dsp_clk_a_div,
		CLKIN_IBUFG_OUT => open,
		CLK0_OUT => dsp_clk_a,
		LOCKED_OUT => LOCKED_a
);
i_locked_a_reg : FDE port map (Q => locked_a_reg, C => dsp_clk_a, CE
=> '1', D => LOCKED_a);
nreset_and_locked <= locked_a_reg;

All the electronics will be at reset state until the DCM is locked. I
use the LOCKED signal to generate the reset for all FFs, and DCM's
output clock (dsp_clk_a) as the clock signal for all FFs.

Is my approach wrong? Why does Xilinx ISE not detect setup/hold
violations?

Thanks in advance.


Article: 119521
Subject: Re: Xilinx doesn't detect setup/hold violations on synchronous reset
From: John_H <newsgroup@johnhandwork.com>
Date: Tue, 22 May 2007 00:47:20 GMT
Links: << >>  << T >>  << A >>
Frai wrote:
> Hi all,
> 
> I am facing some problems with Xilinx ISE 8.2 not taking into account
> synchronous reset setup/hold violations on FFs. My code looks like
> this:
> 
> Inst_my_dcm_a: my_dcm
> 	PORT MAP(
> 		CLKIN_IN => dsp_clk_pad_a,
> 		RST_IN => "not"(nreset),
> 		CLKDV_OUT => dsp_clk_a_div,
> 		CLKIN_IBUFG_OUT => open,
> 		CLK0_OUT => dsp_clk_a,
> 		LOCKED_OUT => LOCKED_a
> );
> i_locked_a_reg : FDE port map (Q => locked_a_reg, C => dsp_clk_a, CE
> => '1', D => LOCKED_a);
> nreset_and_locked <= locked_a_reg;
> 
> All the electronics will be at reset state until the DCM is locked. I
> use the LOCKED signal to generate the reset for all FFs, and DCM's
> output clock (dsp_clk_a) as the clock signal for all FFs.
> 
> Is my approach wrong? Why does Xilinx ISE not detect setup/hold
> violations?
> 
> Thanks in advance.

The timing analysis is configured by default to ignore asynchronous 
set/reset paths and latch element d->q propagation.  You can enable 
these elements with the ENABLE constraint.  Please see your constraints 
guide for more information.

Article: 119522
Subject: Re: Xilinx doesn't detect setup/hold violations on synchronous reset
From: Frai <maybetooparanoid@gmail.com>
Date: 21 May 2007 18:40:35 -0700
Links: << >>  << T >>  << A >>
Hi John.

I knew that. That's one of the reasons why I'm using synchronous
reset. As far as I know Xilinx is enabled by default to trace
synchronous inputs, including set/reset.




Article: 119523
Subject: DDR Controller Blue
From: Digital Mike <michaelmkliu@gmail.com>
Date: 21 May 2007 20:49:02 -0700
Links: << >>  << T >>  << A >>
Dear all,

I am working on a DDR controller that stores captured video frames
from which a VGA controller retrieves data. It (DDR controller) works
fine for the first few frames but seems dead afterward. I wonder if
anyone experienced similar problem. What I did (for initial testing
purpose) is to capture and store a frame into the DDR then retrieve
the same frame (a 640x480 pixels area) over and over again.

Comments?

-M


Article: 119524
Subject: Re: SelectIO banking rules
From: LilacSkin <lpaulo07@iseb.fr>
Date: 21 May 2007 23:56:31 -0700
Links: << >>  << T >>  << A >>
That's my BANK 4:
I don't find the problem !

Pin Name        	Direction  	IO Standard
IO_L49N_4       	BIDIR      	LVTTL
IO_L67N_4       	BIDIR      	LVTTL
IO_L07N_4       	OUTPUT   LVTTL
IO_L19N_4       	OUTPUT   LVTTL
IO_L37N_4       	INPUT      	LVTTL
IO_L43N_4       	BIDIR      	LVTTL
IO_L46N_4       	BIDIR      	LVTTL
IO_L49P_4       	BIDIR      	LVTTL
IO_L67P_4       	BIDIR      	LVTTL
IO_L05_4/No_Pair	INPUT      	LVTTL
IO_L07P_4/VREF_4	OUTPUT   LVTTL
IO_L19P_4       	OUTPUT   LVTTL
IO_L37P_4       	OUTPUT   LVTTL
IO_L43P_4       	BIDIR      	LVTTL
IO_L46P_4       	BIDIR      	LVTTL
IO_L55N_4       	BIDIR      	LVTTL
IO_L73N_4       	BIDIR      	LVTTL
IO_L08N_4       	OUTPUT   LVTTL
IO_L25N_4       	OUTPUT   LVTTL
IO_L38N_4       	INPUT      	LVTTL
IO_L47N_4       	BIDIR      	LVTTL
IO_L55P_4       	TRISTATE LVTTL
IO_L73P_4       	BIDIR      	LVTTL
IO_L08P_4       	OUTPUT   LVTTL
IO_L25P_4       	INPUT      	LVTTL
IO_L26N_4       	OUTPUT   LVTTL
IO_L38P_4       	INPUT      	LVTTL
IO_L47P_4       	BIDIR      	LVTTL
IO_L56N_4       	BIDIR      	LVTTL
IO_L68N_4       	BIDIR      	LVTTL
IO_L74N_4/GCLK3S	INPUT      	LVCMOS25
IO_L20N_4       	OUTPUT   LVTTL
IO_L39N_4       	INPUT      	LVTTL
IO_L26P_4       	INPUT      	LVTTL
IO_L44N_4       	BIDIR      	LVTTL
IO_L50_4/No_Pair	BIDIR      	LVTTL
IO_L56P_4       	BIDIR      	LVTTL
IO_L68P_4       	BIDIR      	LVTTL
IO_L74P_4/GCLK2P	INPUT      	LVCMOS25
IO_L09N_4       	OUTPUT   LVTTL
IO_L20P_4       	OUTPUT   LVTTL
IO_L27N_4       	OUTPUT   LVTTL
IO_L39P_4       	OUTPUT   LVTTL
IO_L44P_4       	BIDIR      	LVTTL
IO_L53_4/No_Pair	BIDIR      	LVTTL
IO_L69N_4       	BIDIR      	LVTTL
IO_L75N_4/GCLK1S	BIDIR      	LVTTL
IO_L06N_4/VRP_4 	OUTPUT   LVTTL
IO_L09P_4/VREF_4	OUTPUT   LVTTL
IO_L21N_4       	OUTPUT   LVTTL
IO_L27P_4/VREF_4	INPUT      	LVTTL
IO_L45N_4       	BIDIR      	LVTTL
IO_L48P_4       	BIDIR      	LVTTL
IO_L48N_4       	BIDIR      	LVTTL
IO_L57N_4       	BIDIR      	LVTTL
IO_L57P_4/VREF_4	BIDIR      	LVTTL
IO_L69P_4/VREF_4	BIDIR      	LVTTL
IO_L75P_4/GCLK0P	INPUT      	LVTTL
IO_L06P_4/VRN_4 	OUTPUT   LVTTL
IO_L21P_4       	OUTPUT   LVTTL
IO_L45P_4/VREF_4	BIDIR      	LVTTL
IO_L54P_4       	BIDIR      	LVTTL
IO_L54N_4       	BIDIR      	LVTTL




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