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 92000

Article: 92000
Subject: Re: Setting the environment variable in ISE 7.1?
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Fri, 18 Nov 2005 15:21:00 -0800
Links: << >>  << T >>  << A >>
-- Creates an ERROR:Place:645 if UCF file LOCs pins to non clock inputs
-- cam1_xclk_ibufd_inst : IBUFDS
-- port map (
--   O  => cam1_xclk,  -- to DCM input
--   I  => gpio_exp_hdr2(7),
--   IB => gpio_exp_hdr2(6) );

-- This code didn't help the ERROR:Place:645 / WARNING:Place:644 problem
-- Does improve the route if one moves the pins to a clock input

-- cam1_xclk_ibufgds_inst : IBUFGDS
-- generic map (
-- --   DIFF_TERM => "FALSE",    -- Differential Termination (Virtex-4 only)
-- --    Above line created a TYPE error
-- --    Language Template differs from v4ldl libraries guide.
-- --   IBUF_DELAY_VALUE => "0",
-- --  Specify the amount of added input delay for buffer,
-- --   "0"-"16" (Spartan-3E only)
--   IOSTANDARD => "DEFAULT")
-- port map (
--   O  => cam1_xclk,
--   I  => gpio_exp_hdr2(7),
--   IB => gpio_exp_hdr2(6));

-- This code does not get rid of WARNING:Place:644 but
-- does improve the appearance of the internal clock route
-- even though the UCF file has the pins LOC to non clock inputs

   cam1_xclk_ibufd_inst : IBUFDS
 port map (
   O  => cam1_xclk_intermediate,
   I  => gpio_exp_hdr2(7),
   IB => gpio_exp_hdr2(6) );

 cam1_xclk_bufg : BUFG
 port map (
   O => cam1_xclk,  -- to DCM input
   I => cam1_xclk_intermediate );

Brad Smallridge
aivision.com




Article: 92001
Subject: Re: hi everyone, tell me something about Cyclone II.
From: "gallen" <arlencox@gmail.com>
Date: 18 Nov 2005 16:35:18 -0800
Links: << >>  << T >>  << A >>
Austin, I have to disagree with you about most designs being done with
fpgas and there being loads of jobs in the market.  I fairly recently
graduated from school with a computer engineering degree.  I did a lot
of FPGA work while I was in school using both Xilinx and Altera
platform (as for the X vs. A debate, I'm agnostic, I find Xilinx's
tools to be more complete, but I find Altera's GUI to be nicer).
Despite doing all of that FPGA work I did not find a single job having
anything to do with FPGAs.  However, I worked for an ASIC company that
was not on your list and now I work for a different ASIC company.  I
get the impression that ASICs are still very popular despite their
rising NRE costs.

All that said, I do recommend looking at all the FPGA stuff you can.
Regardless of whether you go into ASICs or FPGAs in your career, FPGA
development will give you a *GREAT* background.  I might even go so far
as to say that FPGA development will give you a better modern digital
design background that most of the old-timer engineers have.

My experience has been that FPGAs teach all of the fundamentals:
* basic logic design
* static timing
* hand optimization to meet timing
A couple of things are skipped like:
* electromigration
* cross-talk
* voltage-domain crossing

But really FPGAs offer most of what you need.  The really big thing
that they do that many of the "old-timers" don't get is they force you
to reduce the number of clock domains you have.  FPGAs have a very
limited number of global clock nets.  As a result you learn that it's
best to not generate a clock for every single flip flop that's driven
or to put HUGE amounts of logic in a clock net or to do loads of async
design.  This is a great thing to get used to since modern ASIC and
FPGA flows do not adapt well to this.

I might also add that when you're looking at internships and first jobs
that it's best not to expect to do exactly what you want.  You can ask
around to all of your profs to see if they have contacts, but my
experience has been that it is generally not the case.  My profs seemed
to like to avoid FPGAs like the plague and generally thought that
digital design was for the weak (or something since they did a pretty
lousy job of teaching it in my opinion).

Good luck.  Also, don't be afraid to apply for jobs that you're
under-qualified for.  A lot of companies put up requirements that are
completely outlandish hoping for a miracle, but expecting much less.
If a job says 5 years experience required.  Go ahead.  Apply for it!

-Arlen


Article: 92002
Subject: Re: hi everyone, tell me something about Cyclone II.
From: "Subroto Datta" <sdatta@altera.com>
Date: Sat, 19 Nov 2005 00:39:26 GMT
Links: << >>  << T >>  << A >>
To get a good idea of the type of applications that Cyclone II /Cyclone 
devices are used in check the following link:

http://www.altera.com/corporate/cust_successes/customer_showcase/view_product/csh-vproduct-cyclone.jsp

The use of these devices in an application is only limited by your 
imagination. Remember you can have your own NiosII processor running on 
these chips, to allow you greater flexibility and creativity. In a student 
competition sponsored by Altera, one of the winners implemented a biometric 
system running on a Cyclone chip using the UP3 board.

Happy experimentation,
Subroto Datta
Altera Corp.

"badgrant" <badgrant@yahoo-dot-com.no-spam.invalid> wrote in message 
news:V5idnQ62EdUrBuDeRVn_vA@giganews.com...
> hi, i'm grant, studying computer engineering in university of ottawa.
> i'm using altera cyclone II on up3 board with quartus II enviorment.
> how is it? is it leading in industry? what kind of job can i get when
> i'm done.
>
> guys, forgive me if i have tons of questions, coz i do care about my
> career while i know nothing about it right now. :p
> 



Article: 92003
Subject: Help Needed Regarding VPR
From: vivekgarg330@gmail.com
Date: 18 Nov 2005 21:50:05 -0800
Links: << >>  << T >>  << A >>
Hi,

We need to evaluate new CLB architectures for routing area and delay.
In VPR how can I specify my CLB architecture accurately. In
architecture file all I could find out was that we can change number of
LUTs and their input size. But in our architectures apart from LUTs we
also have some extra combinational modules. Is it possible for me to
specify no of transistors that my CLB takes in VPR and then let VPR do
placement and routing because that will give routing area and delay
according to our architecture. If yes where should I do that.
I feel that currently VPR finds out number of transistors of a CLB
based on number of LUTs present but I was unable to figure out where
does it use this information after going through the code.

Kindly help me if someone has gone through the code or has modified it.

Thanks and regards,


Article: 92004
Subject: Oh no! Resets Again? Yes, but it could be important.
From: "JustJohn" <john.l.smith@titan.com>
Date: 19 Nov 2005 02:57:01 -0800
Links: << >>  << T >>  << A >>

Important if you need your designs to cleanly reset every time.

Apologies, but many folks are still posting code for asynchronous
resets... some are even advocating it:

On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:

"I use exactly this template of three top procedures in every new
design entity:

  begin -- process template
    if reset = '1' then
      init_all_regs; -- no port init required
    elsif rising_edge(clock) then
      update_process_regs;
    end if;
    update_output_ports; -- wires ok for reset or clk
  end process template;
"
This is only the most recent example, and seeing this asynchronous
reset code over and over again is starting to worry me, particulary
considering that some FPGA's may be in critical environments, where
cleanly coming out of reset is vital.

Xilinx[Ken Chapman] suggests this is not the most efficient strategy
for LUT utilization in http://tinyurl.com/66xby. Ken cheats a bit in
his article (he re-works an async reset to be sync to get a more
compact circuit, but the behavior of the smaller circuit is different
than the original!), but overall he has a good point. And there is a
stronger reason to write your code to reset synchronously. The
following is quoted verbatim from the Xilinx Constraints Guide
(cgd.pdf), in the Timing Constraints section:

"The tools do not automatically analyze asynchronous set/reset paths."
(I assume tools means Map/Place/Route)

This bears repeating.
"The tools do not automatically analyze asynchronous set/reset paths."

Following that scary statement is a reference to the "Enable" and
"Disable" constraints, which control timing checks over these two paths
(among others):

"Asynchronous Set/Reset to output propagation delay"
 and
"Synchronous Set/Reset to clock setup and hold checks"

But lo and behold! There is NO checking (according to cgd above) of the
path:

"Asynchronous Set/Reset to clock setup and hold checks"

(I like the convention of calling "async reset" clear, and calling
"async set" preset, leaving set/reset for the sync functions, and will
try to stick with that for the rest of this discussion)

The clear pin may be released at various registers in a process with
uncertain timing relative to clock, _even_ if the clear signal started
out synchronous. This has the same potential for trouble as any other
async input to a synchronous state machine, because clear is just
another input after all. A one-hot state machine can go no-hot or
many-hot; a binary coded (non-Gray) SM may enter an illegal state; or
see Ray's counter example (which is _not_ a counter-example) at
http://tinyurl.com/8gjxe. These are not good things.

I've modified my style to ALWAYS reset synchronously, using a sync
reset (with considered exceptions for certain unique circuits):

process(clock)
begin
    if RISING_EDGE(clock) then
      if reset = '1' then
        init_regs; -- the ones that need it.
      else
      [elsif enable = '1' then] -- I like this form, it's free
        update_process_regs;
    end if; end if;
end process;

Sure, it means that reset has to be synchronized somewhere, and (egad,
worse yet!) typing an extra "end if" and indenting a level deeper, but
this is a small price to pay for designs that start up first time,
every time.

To quote Ray:
" Generally speaking, asynchronous resets are a very bad idea in
FPGAs."
Because this might be mis-interpreted, I'd clarify that and say even
synchronous resets, if used as a clear function, are a bad idea. Write
code to reset synchronously. Keep clear of that clear pin.

Regards to all,
John


Article: 92005
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "Raymund Hofmann" <filter002@desinformation.de>
Date: Sat, 19 Nov 2005 14:23:29 +0100
Links: << >>  << T >>  << A >>

"JustJohn" <john.l.smith@titan.com> schrieb im Newsbeitrag 
news:1132397821.560864.109950@g49g2000cwa.googlegroups.com...
>
> On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:
>
> "I use exactly this template of three top procedures in every new
> design entity:
>
>  begin -- process template
>    if reset = '1' then
>      init_all_regs; -- no port init required
>    elsif rising_edge(clock) then
>      update_process_regs;
>    end if;
>    update_output_ports; -- wires ok for reset or clk
>  end process template;
> "

Do you want to take the fun out of the world of electronic design ?

> This is only the most recent example, and seeing this asynchronous
> reset code over and over again is starting to worry me, particulary
> considering that some FPGA's may be in critical environments, where
> cleanly coming out of reset is vital.

Our evolution is try and error. Do you want to hinder our evolution ?
Do you want to take the exitement out of our lives ?

And Frankly, every modern (since the Wintel revolution) user of any 
electronic device will "reboot" it until it works without worrying. I've 
already adapted this behaviour subconsciously.
I also experience a much higher rate of failure during operation of 
electronic devices.

Raymund Hofmann 


Article: 92006
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: allanherriman@hotmail.com
Date: 19 Nov 2005 08:41:54 -0800
Links: << >>  << T >>  << A >>
JustJohn wrote:
> "The tools do not automatically analyze asynchronous set/reset paths."
> (I assume tools means Map/Place/Route)
>
> This bears repeating.
> "The tools do not automatically analyze asynchronous set/reset paths."


You can turn this on the UCF.  Every UCF I have ever written has
contained the lines:

# magic incantation to make the tools trace timing through reset paths
ENABLE= reg_sr_q;


Regards,
Allan


Article: 92007
Subject: Functional problems with Stratix II when configuring at higher temperatures?
From: "henn_xxx@trispel.org" <henn2005@trispel.org>
Date: 19 Nov 2005 08:58:20 -0800
Links: << >>  << T >>  << A >>
Hello,

in my project I have 20 boards with an Altera Stratix II EP2S60 FPGA.
When configuring and operating at room temperature (e.g. around 20 deg
C), everthing works as expected. When configuring at room temperature
and raising the operating temperature to 70=B0 (I have the temp sensing
diode connected in the FPGA and can measure the FPGA temperature),
still everythings works as it should.

The problems start, when configuring at higher temperatures. From my 20
boards, I tested 17 for this behaviour:

5 FPGAs are ok up to maximum tested temperature of 70=B0C
6 FPGAs fail between 60..70=B0C
2 FPGAs fail between 50..60=B0C
1 FPGA fails between 45..50=B0C
3 FPGAs fail below 45=B0C

One obvious failure I observe are output pins which are set to GND in
the design - no other logic driving them. The output pin is pulled high
with a 10k resistor. When ok, the output signal is of course low. When
failing, the output pins are floating, which results in the signal
being pulled high by the pull-up resistor.

A second, more difficult to observe failure case is internal. I have a
PCI interface with plain old 32bit, 33MHz. When ok, the software driver
reads internal registers with valid values. During failure cases, some
registers are not determined.

As I started, when the configuration was done at room temperature,
everyting is ok, even if temperature rises to 70 deg C.

I observed the power supplies 1.2V (core) and 3.3V (I/O), they are
solid ok, no dropouts detectable with a scope. The board is an 18 layer
PCB with of course dedicated power planes and good bypassing.

In the tests it did not matter, how the FPGA was configured; JTAG or
passive parallel. Both method had the same results.

Has anybody observed something like this before or can give hints,
where I could at?

Thanks a lot in advance,

Henning


Article: 92008
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: Duane Clark <dclark@junkmail.com>
Date: Sat, 19 Nov 2005 17:00:36 GMT
Links: << >>  << T >>  << A >>
JustJohn wrote:
> Important if you need your designs to cleanly reset every time.
> 
> Apologies, but many folks are still posting code for asynchronous
> resets... some are even advocating it:
> 
> On Nov 11, over in thread "Open Source FPGA...", Mike Treseler wrote:
> 
> "I use exactly this template of three top procedures in every new
> design entity:
> 
>   begin -- process template
>     if reset = '1' then
>       init_all_regs; -- no port init required
>     elsif rising_edge(clock) then
>       update_process_regs;
>     end if;
>     update_output_ports; -- wires ok for reset or clk
>   end process template;
> "
> This is only the most recent example, and seeing this asynchronous
> reset code over and over again is starting to worry me, particulary
> considering that some FPGA's may be in critical environments, where
> cleanly coming out of reset is vital.
> 

Without seeing the rest of Mike's code, I would be willing to bet that 
"reset" is in fact the Xilinx power on reset. This reset is going to 
happen in the actual hardware asynchronously whether you like it or not. 
All Mike has done (I assume) is to explicitely code the actual behavior 
of the builtin Xilinx hardware. This is in fact a perfectly reasonable 
thing to do, and I also insist on all VHDL code I control explicitly 
show asynchronous POR behavior, in the same way.

If a particular part of the circuit needs a synchronous reset, then that 
is simply added to the synchronous part of the process. That is a 
completely separate issue from POR.

Article: 92009
Subject: input in spartan kit(its urgent)
From: ravindra28d@rediffmail-dot-com.no-spam.invalid (ravindra kalla)
Date: Sat, 19 Nov 2005 11:15:25 -0600
Links: << >>  << T >>  << A >>
hi, 

I made a programe for block matching motion estimation.In this i have
to compare the (4*4) matrics of current frame,with 18,(4*4) mtrics of
search frame.each element of matrics is pixel value(containing 8
bit).In first clock cycle (1,1) element of all the matrics is going
to the 19 inputs of the programe.In next clock cycle(1,2) elements of
all matrics will be on the inputs.Their is 18 processing element
inside the programe,each processing element getting one input from
search frame and one input from data frame.data frame input is common
in all processing element. 

so i have to give 18(search frame pixel)+1 data frame pixel in every
clock cycle in my verilog programe. 

now for implementing this in FPGA,i m using sparta3xp200ft256,that is
having 100 I/O pin,but i require more input pin. 
please suggest any method to reduce input pin,so that i can check it
in spartan kit. 
How can i give test signal to spartan signal for this by using xilinx
webpack7.1i


Article: 92010
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "JustJohn" <john.l.smith@titan.com>
Date: 19 Nov 2005 09:35:28 -0800
Links: << >>  << T >>  << A >>
This is interesting Allan...

 I did read the docs, that's where I quoted from. Are you saying that
ENABLE= reg_sr_q; which provides timing coverage for paths including:

1) "Asynchronous Set/Reset to output propagation delay"

will eventually somehow undergo a transformation into a check for paths
including:

2) "Asynchronous Set/Reset to clock setup and hold checks"

Because I am not talking about a reset -> output issue, This is a
matter of set-up/hold. Another Enable/Disable constraint, reg_sr_clk,
as listed in Tables 7-1 and 7-2, gives path checking for

3) "Synchronous Set/Reset to clock setup and hold checks"

but 3) is clearly different from 2). Do you see the difference I'm
suggesting?

Either my reasoning is totally kaflooeey, or the Xilinx documentation
is fairly misleading and should be changed to something like:

Enable = reg_sr_clk; implies
4) Any (Synchronous or Asynchronous) Set/Reset to clock setup and hold

It might be nice to have someone from Xilinx weigh in on this.

Regards,
John


Article: 92011
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: John_H <johnhandwork@mail.com>
Date: Sat, 19 Nov 2005 17:39:38 GMT
Links: << >>  << T >>  << A >>
JustJohn wrote:
> This bears repeating.

   This bears   This bears  This bears   This bears   This bears


Anyway, two things:

1) Do you guarantee a power-on reset either by always asserting the 
reset pin or through constraints?

2) What if your system is in an environment where the clock is stopped 
during your reset event?


Power-on states are guaranteed by the asynchronous reset.  Those of us 
who try to keep away from async resets MUST make sure there isn't an 
erroneous power-up state that confuses our logic OR guarantee that 
everything has the synchronous reset applied before the circuit affect 
the rest of our system.

Article: 92012
Subject: Re: hi everyone, tell me something about Cyclone II.
From: austin <austin@xilinx.com>
Date: Sat, 19 Nov 2005 09:50:04 -0800
Links: << >>  << T >>  << A >>
Gallen,

A different story that the one I have been hearing.

I am glad to hear there are still good ASIC jobs around (Xilinx has 
openings unfilled as well).

But, I still stand by my comment that FPGA jobs are more common that 
ASIC jobs:  in fact perhaps as much as 1000:1 more common.

Consider yourself very fortunate to be doing ASIC design.

Austin

gallen wrote:

> Austin, I have to disagree with you about most designs being done with
> fpgas and there being loads of jobs in the market.  I fairly recently
> graduated from school with a computer engineering degree.  I did a lot
> of FPGA work while I was in school using both Xilinx and Altera
> platform (as for the X vs. A debate, I'm agnostic, I find Xilinx's
> tools to be more complete, but I find Altera's GUI to be nicer).
> Despite doing all of that FPGA work I did not find a single job having
> anything to do with FPGAs.  However, I worked for an ASIC company that
> was not on your list and now I work for a different ASIC company.  I
> get the impression that ASICs are still very popular despite their
> rising NRE costs.
> 
> All that said, I do recommend looking at all the FPGA stuff you can.
> Regardless of whether you go into ASICs or FPGAs in your career, FPGA
> development will give you a *GREAT* background.  I might even go so far
> as to say that FPGA development will give you a better modern digital
> design background that most of the old-timer engineers have.
> 
> My experience has been that FPGAs teach all of the fundamentals:
> * basic logic design
> * static timing
> * hand optimization to meet timing
> A couple of things are skipped like:
> * electromigration
> * cross-talk
> * voltage-domain crossing
> 
> But really FPGAs offer most of what you need.  The really big thing
> that they do that many of the "old-timers" don't get is they force you
> to reduce the number of clock domains you have.  FPGAs have a very
> limited number of global clock nets.  As a result you learn that it's
> best to not generate a clock for every single flip flop that's driven
> or to put HUGE amounts of logic in a clock net or to do loads of async
> design.  This is a great thing to get used to since modern ASIC and
> FPGA flows do not adapt well to this.
> 
> I might also add that when you're looking at internships and first jobs
> that it's best not to expect to do exactly what you want.  You can ask
> around to all of your profs to see if they have contacts, but my
> experience has been that it is generally not the case.  My profs seemed
> to like to avoid FPGAs like the plague and generally thought that
> digital design was for the weak (or something since they did a pretty
> lousy job of teaching it in my opinion).
> 
> Good luck.  Also, don't be afraid to apply for jobs that you're
> under-qualified for.  A lot of companies put up requirements that are
> completely outlandish hoping for a miracle, but expecting much less.
> If a job says 5 years experience required.  Go ahead.  Apply for it!
> 
> -Arlen
> 

Article: 92013
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: allanherriman@hotmail.com
Date: 19 Nov 2005 10:30:24 -0800
Links: << >>  << T >>  << A >>
JustJohn wrote:
> This is interesting Allan...
>
>  I did read the docs, that's where I quoted from. Are you saying that
> ENABLE= reg_sr_q; which provides timing coverage for paths including:
>
> 1) "Asynchronous Set/Reset to output propagation delay"
>
> will eventually somehow undergo a transformation into a check for paths
> including:
>
> 2) "Asynchronous Set/Reset to clock setup and hold checks"

Quite possibly.  It wouldn't be the first time Xilinx software did
something completely contrary to the documentation.  At least reg_sr_q
is mentioned in the documentation now (it wasn't always).

I'm a bit confused as to why you would attempt to use async resets to
implement logic functions that are better handled by synchronous
resets.  At least with synchronous resets you can know that the results
will be reliable.  If I caught any of the designers here trying to use
async resets that way they would get a stern talking to.

Any reasonable FPGA coding guide should strongly advise against using
async resets or sets to implement logic functions.  (At least for
Xilinx) async resets should only be connected to one net, and that net
should be connected to the reset input of a startup block.  Any other
usage should be illegal.  You should use a well known name for that net
as well.  Here we use the name 'gsr'.

Such guidelines are based upon studies made of non-working designs and
failing projects over many years.  You can ignore them at your peril.

Allan


Article: 92014
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "JustJohn" <john.l.smith@titan.com>
Date: 19 Nov 2005 10:40:38 -0800
Links: << >>  << T >>  << A >>
John_H wrote:

> This bears   This bears  This bears   This bears   This bears

HA HA HA, Thanks for the smile this morning, I was up late last night
when I made that post, maybe got too long winded.

> 1) Do you guarantee a power-on reset either by always asserting the
>reset pin or through constraints?

Hmm, to answer both John and Duane, I was talking about an individual
reset for an entity, that may be asserted individually to that entity,
separate from others in the same design and not "globally" across the
chip, as a power-on reset. Perhaps code examples here in c.a.f. can
make the distinction, and generally use 'por' for power-on resets, and
'rst' for not necessarily global resets.

Personally, I admit to being a little lazy, and writing code so that
power-on state is irrelevant for most of the the system, except in one
place where a rst event is guaranteed to be generated. That rst does
the real work, and does not depend on the whether the FPGA has a por or
not.

>2) What if your system is in an environment where the clock is stopped
>during your reset event?

I'll duck this for now and say that's one of the "considered exceptions
for certain unique circuits". Hey, it's Saturday morning, and a bright
and sunny day here in southern California. Time to get outside.


Article: 92015
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "JustJohn" <john.l.smith@titan.com>
Date: 19 Nov 2005 10:59:54 -0800
Links: << >>  << T >>  << A >>
Allan wrote:
>I'm a bit confused as to why you would attempt to use async resets to
>implement logic functions that are better handled by synchronous
>resets.

Apologies to you Allan, I was not trying to confuse you, and I would
NOT attempt such a thing, this was exactly the point of my post! Xilinx
docs say they don't check clock set-up for asynchronous reset input,
and yet, time after time, people post examples of async resets, which
will lead the unwary into trouble.
As I said on the other thread, it's a nice day out, time for a walk...


Article: 92016
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: allanherriman@hotmail.com
Date: 19 Nov 2005 11:33:00 -0800
Links: << >>  << T >>  << A >>
JustJohn wrote:
> Allan wrote:
> >I'm a bit confused as to why you would attempt to use async resets to
> >implement logic functions that are better handled by synchronous
> >resets.
>
> Apologies to you Allan, I was not trying to confuse you, and I would
> NOT attempt such a thing, this was exactly the point of my post! Xilinx
> docs say they don't check clock set-up for asynchronous reset input,
> and yet, time after time, people post examples of async resets, which
> will lead the unwary into trouble.
> As I said on the other thread, it's a nice day out, time for a walk...

I started out using TTL parts.  They (usually) didn't specify setup
times of async inputs with respect to the clocks.  Propagation delay
(async reset -> Q) was the only timing parameter specified.
(I just checked the data sheet for a SN54AHC74, it seems these
parameters are specified in more contemporary devices.)

I feel this is more about educating newbies than blaming Xilinx for
faults in their tools.
Surely schools teach ... wait, I can remember my classes (a long time
ago) and they didn't even touch on this sort of thing.

(I'll follow your lead and take a walk outside now.)

Regards,
Allan


Article: 92017
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sat, 19 Nov 2005 11:38:28 -0800
Links: << >>  << T >>  << A >>
JustJohn wrote:

> Hmm, to answer both John and Duane, I was talking about an individual
> reset for an entity, that may be asserted individually to that entity,
> separate from others in the same design and not "globally" across the
> chip, as a power-on reset.

My code template assumes one global reset pulse
that occurs once, on a low-skew path,
after the fpga image has loaded.
I also assume that this pulse has a source
external to, but using the same clock as the fpga.
In my case, it comes from a cpu that loads
the binary fpga image.

I don't use vendor-specific resets
because they are vendor-specific.

The reason I use this "asynchronous" style template
is that it saves logic cells in every synthesis benchmark I have run
on both brands A and X.

In summary, I use one synchronized reset pulse,
on a low skew path to the asynch reset input
of every D-flop in the design.

I expect that this template will work for me
as long as fgpa vendors keep global routing
and asynch resets on D-flops.

I will update my code examples with these comments.

      -- Mike Treseler

Article: 92018
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 19 Nov 2005 13:48:25 -0600
Links: << >>  << T >>  << A >>

>My code template assumes one global reset pulse
>that occurs once, on a low-skew path,
>after the fpga image has loaded.
>I also assume that this pulse has a source
>external to, but using the same clock as the fpga.
>In my case, it comes from a cpu that loads
>the binary fpga image.

Is that good enough?

Don't you also need the prop time on that low-skew path
to be short enough relative to your clock cycle time so
that you know when it gets to your FFs?

Last I checked, the global reset on most Xilinx parts
was too slow to be useful in that context.

I thought that consensus here was to use the global
reset hardware to (asynchronously) force your state
machines into a known state and then use a local
FF that has been synchronized to get out of that state.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 92019
Subject: Re: hi everyone, tell me something about Cyclone II.
From: "gallen" <arlencox@gmail.com>
Date: 19 Nov 2005 13:28:19 -0800
Links: << >>  << T >>  << A >>
I suppose I should mention that consumer level products are often where
the ASICs lie.  In situations where there may only be 10s, 100s or
1000s of parts, FPGAs may be very common.  My work currently gets
manufactured in the 100s of millions and it contains a large analog
block.  It just simply isn't suited for FPGA.

I could see FPGAs being big in high end space (I think Cisco uses FPGAs
for its backbone class routers).  I could see them in government space.
 I could see them in prototypes (heck, our architects use them for
accellerating matlab tests).  I just can't see them making much inroads
into high volume consumer space.

The important detail to be taken from this though is that ASICs are
still very alive for very high volume work as well as high speed
(multi-GHz) and analog.

Best of luck to all of those students out there hunting.  There is an
amazing amout of interesting work to be done.  Also, pay attention in
your signal processing classes.  That is some really important stuff.
-Arlen


Article: 92020
Subject: Assertion file update problem in ModeSim (via Tcl script)
From: Alex <al.lopich@gmail.com>
Date: Sat, 19 Nov 2005 22:29:12 -0000
Links: << >>  << T >>  << A >>
Hi guys,

I experience some problem with modeling some designs in ModelSim 5.7 XE  
2/Starter trough Tcl script.

I have a set of designs with corresponding testbenches, and while running  
simulations through

eval vsim -assertfile $log_file testbench

I am facing the problem that ModelSim updates files only when it is being  
closed.
I.e. the files are created but I can access them straight after the  
simulation:

vsim -assertfile $log_file testbench
run &time
quit -sim

So if i run script one more time I am already able to access necessary  
information, but I am looking for solution
to accomplish it in one go.
Am I missing something (some design,project closing, or probably ModelSim  
settings )??
Thanks for help.

--
Alex


Article: 92021
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "Mike Treseler" <mike_treseler@comcast.net>
Date: Sat, 19 Nov 2005 16:15:12 -0800
Links: << >>  << T >>  << A >>
Hal Murray wrote:

> Is that good enough?

It has been in many cases.

> Don't you also need the prop time on that low-skew path
> to be short enough relative to your clock cycle time so
> that you know when it gets to your FFs?

For the trailing edge, yes.
On the board, a zero delay clock buffer
and careful distribution to all devices does
the trick. On the fpga I just have to make
sure the reset node gets one of the global nets.

> Last I checked, the global reset on most Xilinx parts
> was too slow to be useful in that context.

Yes. I don't use anyone's the built-in reset.

> I thought that consensus here was to use the global
> reset hardware to (asynchronously) force your state
> machines into a known state and then use a local
> FF that has been synchronized to get out of that state.

I don't think I'm contradicting that idea.
The asynch reset gives you a starting
point for simulation. After this, well-designed
control logic will use an idle state for
specific synchronous initialization.

           -- Mike Treseler

Article: 92022
Subject: Asynchronous design
From: "Chintan" <cvdagli@yahoo.com>
Date: 19 Nov 2005 16:46:41 -0800
Links: << >>  << T >>  << A >>
Hi,
  I am designing a peripheral interface IO chip which is also the Intel
i82C55 chip. THe problem I have is I want to change a interrupt signal
INTR to '1' at the rising edge of a strobe input (STB) and then later
change INTR to '0' when the read signal (RD) arrives (at the rising
edge of RD). My VHDL code is

handshaking: process(STB, RD) is
begin
		if rising_edge(STB) then
				INTR <= '1';
				STATUS_REG(2) <= '1';
		end if;

		if rising_edge(RD) then
                                INTR <= '0';
				STATUS_REG(2) <= '0';
               end if;

end process;

   It seems that this is a bad synchronous design. So, how can I change
my INTR signal to respond to STB and RD signals?
     Any help is highly appreciated...

 THank you all


Article: 92023
Subject: Re: Oh no! Resets Again? Yes, but it could be important.
From: "JustJohn" <john.l.smith@titan.com>
Date: 19 Nov 2005 16:55:32 -0800
Links: << >>  << T >>  << A >>
(Back from my walk...)

Hal wrote:

>I thought that consensus here was to use the global
>reset hardware to (asynchronously) force your state
>machines into a known state and then use a local
>FF that has been synchronized to get out of that state.

Aaahhh, thanks Hal, _very_ nicely put, succinct and clear. (It's been a
while since those discussions, I turned 50 last month, and have been
working in the wonderful world of M$ GUI design lately, so forgive me
for forgetting).

Integrating everyone's good words with Mike's generic process template
and my desire for an entity local reset into pseudo VHDL:

process (clock, gsrout) begin
  if gsrout = '1' then
    init_all_regs;   -- Every darn one of them
    init_state_regs; -- To a 'dormant' reset state
  elsif RISING_EDGE(clock) then
    if reset = '1' then
      init_some_regs;   -- Only ones really that need it,
                        -- both to reduce routing req's,
                        -- and because it may be useful
                        -- to keep some values across
                        -- a reset event
      init_state_regs2; -- To an 'awake' reset state
    else                -- No enable form
    [elsif enable = '1' then] -- Using enable form
      run_reg_logic;    -- And they're off to the races
      run_state_logic;  -- (oops, bad word, no races here!)
  end if; end if;
 end process;

Signal gsrout comes from the Xilinx 'STARTBUF_arch' primitive, so that
the async device clear does not take FF pins or routing. (Mike may not
like this vendor specific stuff, see my parting question)

Googling back to June reveals a 'roller' (http://tinyurl.com/ajvtw) who
asked about _not_ using this format. Nobody answered then, but after
going through this exercise, I would say this is a fairly solid
template, don't use it at your own peril.

Ok, I'm done, except for one last question... does Altera have a
similar GSR function? (Please pardon my laziness)

Thanks all,

John


Article: 92024
Subject: Re: Asynchronous design
From: Tim Wescott <tim@seemywebsite.com>
Date: Sat, 19 Nov 2005 17:28:57 -0800
Links: << >>  << T >>  << A >>
Chintan wrote:

> Hi,
>   I am designing a peripheral interface IO chip which is also the Intel
> i82C55 chip. THe problem I have is I want to change a interrupt signal
> INTR to '1' at the rising edge of a strobe input (STB) and then later
> change INTR to '0' when the read signal (RD) arrives (at the rising
> edge of RD). My VHDL code is
> 
> handshaking: process(STB, RD) is
> begin
> 		if rising_edge(STB) then
> 				INTR <= '1';
> 				STATUS_REG(2) <= '1';
> 		end if;
> 
> 		if rising_edge(RD) then
>                                 INTR <= '0';
> 				STATUS_REG(2) <= '0';
>                end if;
> 
> end process;
> 
>    It seems that this is a bad synchronous design. So, how can I change
> my INTR signal to respond to STB and RD signals?
>      Any help is highly appreciated...
> 
>  THank you all
> 
Code up an RS latch?

INTR = ~(RD  | Q);     // I think I have
Q    = ~(STB | INTR);  // this right

That way you are at least making your latch out of purely combinatorial 
elements, and aren't depending on the chip being able to detect the 
rising edges of your strobe and read pulses.

I'd be inclined to catch the strobe and read pulses, synchronize them 
with my internal clock, and have a state machine that implements the 
above logic.  The biggest drawback you'll have then is that the INTR 
line will go low a bit after the read goes high, but unless your logic 
is being clocked way slower than the processor you should be OK.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.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