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 132475

Article: 132475
Subject: Re: signal value at power up
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 28 May 2008 08:58:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 27, 1:42=A0am, marts...@gmail.com wrote:
> On May 27, 12:25 am, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
> wrote:
>
>
>
>
>
> > On 27 Mai, 05:18, marts...@gmail.com wrote:
>
> > > signal x: std_logic;
>
> > > you don't assign any value to "x"
> > [..]
> > > how does the x power up? high/low?? is that part/technology dependent?=

>
> > > the reason I am asking this is because, I have a part that used to
> > > work all the time but now I got a different part (same mfg),
> > > programmed with the same programming file and it seems like x is
> > > powering up differently.
>
> > Try a Reset on Power up.
> > For most FPGAs there is a global value for Powerup content that is
> > valid before you use a reset.
> > First of all, inspect the synthesis result. Only latches and FF are
> > set during power up. All other signals depend on the contentg of
> > Inputs, FF and latches.
>
> > bye Thomas
>
> Thomas,
>
> Thanks for your input. But what I was trying to figure out is
> that...If I am not using the reset, or not assign any values to
> signal, what happens in that case? I do know how to fix it but I was
> just curious to find out, why was this working for sometime but now
> doesn't work with a different part (same mfg)?
> Thanks,
> Martin- Hide quoted text -
>

=46rom the synthesis tool's perspective, the lack of any assignment to
'x' in the source code means that it is free to assign anything to
'x'.  Furthermore, because 'y' depends on 'x' it means that the
synthesis tool is free to assign anything to 'y' as well.  There are
five possibilities:
1. x set to '0' which implies that y will be assigned '0' as well.
2. x set to '1' which implies that y will be assigned '1' as well.
3. x connected to some existing signal in the design, which implies
that y will track that signal as well.
4. y connected to some existing signal in the design.
5. y set to 'Z'.

If the synthesis tool chose #1 or #2, you wouldn't see any difference
in the observable output 'y' as you change parts.  Since that is not
what you're observing it would rule out these choices.

If it implemented choice #3 or #4 then you'd have to back track
further to see what is the power up state of the signal that it chose
to connect to 'y'.

If it implemented choice #5 it might appear to power up differently
with a different part because you'd be trying to discern a logic level
from a signal that is not being actively driven.

In any case, the answer to your question lies in the equations file
that was output from place and route.  Take a look for the equations
for output 'y' and the answer to the mystery will (most likely) be
solved.

Kevin Jennings

Article: 132476
Subject: Re: Sequentially syncrhronous
From: KJ <kkjennings@sbcglobal.net>
Date: Wed, 28 May 2008 09:10:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 28, 11:24=A0am, Brian Philofsky
<brian.philofsky@no_xilinx_span.com> wrote:
> KJ wrote:
> > On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
> This very well could be a timing issue but another possible cause of
> this could be the writing of simulatable code but not synthesizable
> code. =A0Looking at the code, I see the signals a and b in the sensitivity=

> list of the process which could cause the else statement to get
> evaluated asynchronously in simulation however for synthesis, the
> sensitivity list is likely ignored (generally with a warning) and thus
> processed differently. =A0

Having 'a' and 'b' in the sensitivity list is not the problem.  The
structure of the code is
process(...)
begin
if (rst =3D '1') then
   ...assignements here
elsif (clk'event and clk =3D '1') then
   ...assignements here
end if;
end process;

There are no assignments to anything outside of the if statement.
That if statement is of the form for flops with async presets/resets.
Having 'extra' signals in the sensitivity list will not result in any
difference between simulation and synthesis.  If it does, then contact
the synthesis tool provider and submit a bug report.

KJ
I suggest removing the a and b signals from the
> sensitivity list and see if the behavioral simulation still works. =A0My
> guess is that may reveal your issue however if that does not, then I do
> suggest looking more closely at the synthesis logs as well as timing
> analysis to ensure it is not another synthesis mis-match issue or timing
> issue.
>
> >> In general, is it always this difficult and fraught with peril? I write=

> >> =A0>2000 lines/month in C++ with only minor misspelling mishaps. These =
50 lines
> >> have caused me more gray hairs than many whole systems.
>
> > Hardware design (even if written in a software like language such as
> > VHDL or Verilog) is not the same as software. =A0You can be well skilled=

> > in the one discipline and at the same time be unskilled in the other.
>
> It is all what you are used to. =A0I can not write C++ worth a lick so it
> would likely take me a long time to write a program using it however I
> feel I am very proficient with VHDL and Verilog.
>
> >> Also, is there a way to tell XST to not treat reset as a clock? I haven=
't
> >> fully read up on configuration, having spent way too much time on this
> >> little time waster.
>
> > What makes you think that it is using reset as a clock?
>
> I imagine you are referring to XST using a global buffer for the reset
> signal. =A0In general this should not cause any issues and many times can
> be the right thing to do but if you want to go to prevent that behavior,
> tell XST you want an IBUF on the reset signal by adding the following
> attribute:
>
> attribute BUFFER_TYPE : string;
> attribute BUFFER_TYPE of rst: signal is "IBUF";
>
> This will force it to use a regular I/O instead of a global buffer.
>
> Hope this helps and do not get too discouraged. =A0If you are just
> learning, I could also suggest you try Verilog over VHDL. =A0I am not
> trying to start the holy wars of languages but many do feel it is less
> of a leap from C to Verilog than VHDL. =A0Again, I am not trying to start
> a language debate so please leave do not let my statement start one.
>
> -- =A0Brian
>
>
>
> >> Last, .... is this really worth pursuing? I've been programming for 25
> >> years, and know that the greatest leassons come after the greatest pain=
. But
> >> there's also good pain, and just senseless injury. Is this not a suitab=
le
> >> first Zen parable to contemplate? I'm goaded forward by the belief that=

> >> there's a good lesson on synchronous systems lurking as the punchline.
>
> > The punchline might be static timing analysis. =A0Signals don't just
> > 'happen' when you want them to, you need to guarantee by design that
> > they arrive at the proper time relative to the clock.
>
> > Kevin Jennings- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -


Article: 132477
Subject: HDL - simulation vs synthesis
From: jared.pierce@gmail.com
Date: Wed, 28 May 2008 09:44:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
I run Xilinx ISE v10.1 and use VHDL.  I have put together a fairly
small circuit that merely sends out solid colors and sync signals on a
VGA line.  During the active video portion of time, a color should
show up on the screen.  The color depends on which of three switches
on my development board are turned on.  There is one for red, green
and blue.

Now the behavioral simulation tells me that the code works exactly as
it is supposed to, however, when I actually implement it on my
development board it does not work.  I have heard of this type of
problem many times, but have no idea where to begin in finding the
fault.

Just so nobody thinks I'm trying too much at once, I did try it
without the switches and told it to just output a solid, unchanging,
color.  That worked.  I tested it for each of the three colors.

The RTL schematic that is generated by ISE shows me that both the
three switches and the red_out, green_out, and blue_out do not exist,
but none of the warning messages that show up tell me that they were
removed.  Can somebody tell me where to begin in solving this issue?
Perhaps a list of things to try / look for or link me to some possible
solution or list of solutions.

Article: 132478
Subject: Re: Sequentially syncrhronous
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Wed, 28 May 2008 12:15:17 -0500
Links: << >>  << T >>  << A >>

"KJ" <kkjennings@sbcglobal.net> wrote in message 
news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com...
On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> Sorry, Guys. We're not quite done yet with the quadrature encoder. I tried
> to rewrite it as a synchronous process. The behavioral sim shows it 
> working
> as intended. The post-route sim and onboard test don't work. 'debouncing'
> never changes state in the sim. The leds don't sequence when I twist the
> magic knob.
>

This is always a symptom of a timing problem.  In your particular case
I suspect the timing of 'a' and 'b' relative to clk is not meeting the
setup/hold time requirements of the device (from your report file).
The signals 'a' and 'b' should be brought into only one flop, the
output of that flop should be fed into a second flop, the output of
that second flop can then be reliably used wherever you currently have
'a' and 'b'.

===================

'a' and 'b' are driven by a hand turned rotary encoder.

I tried buffering them into flops with concurrent statements, a_next and 
b_next, and used a_next and b_next internally. This caused 'a' and 'b' to 
not get routed at all, along with all logic associated with them. The 
circuit was reduced to only those parts lighting the leds.

>>>>>>>>>>>>>>



> Also, is there a way to tell XST to not treat reset as a clock? I haven't
> fully read up on configuration, having spent way too much time on this
> little time waster.

What makes you think that it is using reset as a clock?

======
The synthesis report:

 Number of GCLKs:                         2  out of     24     8%

...

Clock Information:
------------------
-----------------------------------+------------------------+-------+
Clock Signal                       | Clock buffer(FF name)  | Load  |
-----------------------------------+------------------------+-------+
sys_rst_pin                        | IBUF+BUFG              | 1     |
sys_clk_pin                        | BUFGP                  | 7     |
-----------------------------------+------------------------+-------+

Asynchronous Control Signals Information:
----------------------------------------
-------------------------------------------------------------+---------------------------+-------+
Control Signal                                               | Buffer(FF 
name)           | Load  |
-------------------------------------------------------------+---------------------------+-------+
sys_rst_pin                                                  | IBUF 
| 5     |
Inst_q_decode/a_prev_and0000(Inst_q_decode/a_prev_and00001:O)| 
NONE(Inst_q_decode/b_prev)| 2     |
Inst_q_decode/a_prev_and0001(Inst_q_decode/a_prev_and00011:O)| 
NONE(Inst_q_decode/b_prev)| 2     |
-------------------------------------------------------------+---------------------------+-------+

I suppose if I understood what that said, a_prev_andxxxxx are the cause of 
my difficulties.



Article: 132479
Subject: Re: HDL - simulation vs synthesis
From: Jon Beniston <jon@beniston.com>
Date: Wed, 28 May 2008 10:34:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Try a gate-level simulation and see what is going on.

Are you sure there are no warning messages?

Cheers,
Jon

Article: 132480
Subject: Re: asic gate count
From: "vijayant.rutgers@gmail.com" <vijayant.rutgers@gmail.com>
Date: Wed, 28 May 2008 11:24:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have a design on FPGA that is ready. However, we need to have some
mapping from fpga design to asic. I know that this will not be
accurate. But accuracy is not our concern right now. We just need
upper bound.  Also, we are also looking for some IP Core for ASIC so
that we can rough estimate.

Regards,
Vijayant



On May 24, 5:47=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Mike Lewis wrote:
>
> (snip)
>
> >>The traditional method for ASIC is to divide the number
> >>of transistors by the number of transistors in a 2 input
> >>NAND gate. =A0For CMOS, that is four.
>
> (snip)
>
> > What is your method for determining how many transistors are in the desi=
gn?
> > My synthesis tools only give me area.
>
> Last I knew, they gave transistors, but that was some time ago.
>
> For FPGA it is much harder to give a reliable count, and
> you are asking in an FPGA newsgroup.
>
> If it gives gate counts different types of gates and with a
> little guessing on transistors/gate. =A0 Is this for standard
> cell, sea of gates, or something else? =A0I thought I used to
> have pretty detailed information on the standard cell libraries,
> including transistors for each library element.
>
> -- glen


Article: 132481
Subject: Re: HDL - simulation vs synthesis
From: Mike Treseler <mike_treseler@comcast.net>
Date: Wed, 28 May 2008 12:22:07 -0700
Links: << >>  << T >>  << A >>
jared.pierce@gmail.com wrote:

> The RTL schematic that is generated by ISE shows me that both the
> three switches and the red_out, green_out, and blue_out do not exist,

There's your problem.
No registers are being inferred.
Are you using a synchronous process?

        -- Mike Treseler

Article: 132482
Subject: Re: Sequentially syncrhronous
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Wed, 28 May 2008 15:12:22 -0500
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message 
news:357b1d3e-c34e-4ee0-be9d-cb681a4960e3@8g2000hse.googlegroups.com...
> Instead of posting code and asking us to look at it, why don't you
> debug the simulation???  That is what simulations are for.  If you
> said it worked in pre and post layout simulation, but failed on real
> hardware, then it would be a sticky problem that could justify asking
> help.  But if it is failing in simulation, you can dig in and see
> exactly why it is failing.

A fair comment; I often give similar advice.

I removed the rst handling, and now it simulates post-route, but still fails 
in hardware. Could it be the ports? They're configured LVTTL with PULLDOWN. 
The encoder switches are normally-open, grounded, and pulled to VCC when 
they close.

> I am very surprised that this is working in pre-layout sim and failing
> in post.  That is usually a timing problem and I can't imagine that
> you have any timing problems.  Although the synchronization issue that
> KJ mentioned is very valid.

What's really troubling is that something so apparently simple can be 
unstable. I wasn't asking for debug help so much, but help identifying what 
constructs are stable when synthesized and which are prone for trouble. I 
also wasn't expecting trouble.

The synthesis report now says this: "No asynchronous control signals found 
in this design." The only change was to remove rst.

Examining the post-route sim gives no hint where it can be going wrong, or 
what might be borderline. Debounce is a flipflop with clock-enable, 
presumably gated to flop state appropriately. I was concerned about the c-e 
relationship to storing the state for comparison in the next clock cycle, 
but assignment to a_prev and b_prev occur after the clock-enable. It all 
looks as intended.

> To simplify reading your code you might want to break out the
> different functions.  Debounce is normally something done separate
> from the state machine you are implementing.  So put it in a separate
> process and use a separate signal to drive the decoder process. Then
> you have a nice clean signal you can look at to see if the debounce
> process is working correctly.

It turns out that debouncing _is_ the state machine. It drives the counter 
up or down 1 count, which in turn drives the lookup decoder. It was easier, 
and I thought just as clear, to write the single line increment/decrement 
inline.

>
> I am also not too sure of your decoder algorithm.  It is a bit hard to
> read because of the number of indents and the formatting in this
> forum, but it looks like nothing is done with b transitions unless
> they are preceded by an a transition.  I don't think that is an
> optimal approach for a decoder, but maybe this is because you want to
> handle higher speeds.  But if you are getting transitions faster than
> the bounce settles, I don't think the encoder can be decoded.  So none
> of this is clear to me.

On the clock rising edge:
    Check for state change on 'a' if we're not debouncing.
        If 'a' changed state, ignore further changes (debouncing).
        If the change is a rising edge on 'a',
            'b' is the direction of movement.
            Increment or decrement the count accordingly.
    Otherwise, we're already debouncing.
        Clear debounce on the next 'b' change.

It would be more clear to restructure it explicitly as a FSM with the 2 
states. I will do so.



Article: 132483
Subject: FIFO verses RAMB
From: Erik Anderson <erik.k.anderson@gmail.com>
Date: Wed, 28 May 2008 13:51:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
In the Xilinx Virtex 4 architecture, does anyone know when you
instantiate a FIFO using the FIFO16 blocks does the FIFO use the
RAMB16 block next to it for its memory, or does the FIFO16 has its own
dedicated memory (thus leaving the RAMB16 free for other uses)?

Article: 132484
Subject: Re: Sequentially syncrhronous
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 28 May 2008 14:38:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 28, 1:12=A0pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:357b1d3e-c34e-4ee0-be9d-cb681a4960e3@8g2000hse.googlegroups.com...
>
> > Instead of posting code and asking us to look at it, why don't you
> > debug the simulation??? =A0That is what simulations are for. =A0If you
> > said it worked in pre and post layout simulation, but failed on real
> > hardware, then it would be a sticky problem that could justify asking
> > help. =A0But if it is failing in simulation, you can dig in and see
> > exactly why it is failing.
>
> A fair comment; I often give similar advice.
>
> I removed the rst handling, and now it simulates post-route, but still fai=
ls
> in hardware. Could it be the ports? They're configured LVTTL with PULLDOWN=
.
> The encoder switches are normally-open, grounded, and pulled to VCC when
> they close.
>
> > I am very surprised that this is working in pre-layout sim and failing
> > in post. =A0That is usually a timing problem and I can't imagine that
> > you have any timing problems. =A0Although the synchronization issue that=

> > KJ mentioned is very valid.
>
> What's really troubling is that something so apparently simple can be
> unstable. I wasn't asking for debug help so much, but help identifying wha=
t
> constructs are stable when synthesized and which are prone for trouble. I
> also wasn't expecting trouble.
>
> The synthesis report now says this: "No asynchronous control signals found=

> in this design." The only change was to remove rst.
>
> Examining the post-route sim gives no hint where it can be going wrong, or=

> what might be borderline. Debounce is a flipflop with clock-enable,
> presumably gated to flop state appropriately. I was concerned about the c-=
e
> relationship to storing the state for comparison in the next clock cycle,
> but assignment to a_prev and b_prev occur after the clock-enable. It all
> looks as intended.
>
> > To simplify reading your code you might want to break out the
> > different functions. =A0Debounce is normally something done separate
> > from the state machine you are implementing. =A0So put it in a separate
> > process and use a separate signal to drive the decoder process. Then
> > you have a nice clean signal you can look at to see if the debounce
> > process is working correctly.
>
> It turns out that debouncing _is_ the state machine. It drives the counter=

> up or down 1 count, which in turn drives the lookup decoder. It was easier=
,
> and I thought just as clear, to write the single line increment/decrement
> inline.
>
>
>
> > I am also not too sure of your decoder algorithm. =A0It is a bit hard to=

> > read because of the number of indents and the formatting in this
> > forum, but it looks like nothing is done with b transitions unless
> > they are preceded by an a transition. =A0I don't think that is an
> > optimal approach for a decoder, but maybe this is because you want to
> > handle higher speeds. =A0But if you are getting transitions faster than
> > the bounce settles, I don't think the encoder can be decoded. =A0So none=

> > of this is clear to me.
>
> On the clock rising edge:
> =A0 =A0 Check for state change on 'a' if we're not debouncing.
> =A0 =A0 =A0 =A0 If 'a' changed state, ignore further changes (debouncing).=

> =A0 =A0 =A0 =A0 If the change is a rising edge on 'a',
> =A0 =A0 =A0 =A0 =A0 =A0 'b' is the direction of movement.
> =A0 =A0 =A0 =A0 =A0 =A0 Increment or decrement the count accordingly.
> =A0 =A0 Otherwise, we're already debouncing.
> =A0 =A0 =A0 =A0 Clear debounce on the next 'b' change.
>
> It would be more clear to restructure it explicitly as a FSM with the 2
> states. I will do so.

Is somebody trying to re-invent the wheel?
Haven't we been through this in a seemingly endless thread?
Didn't I point out two perfect and compact solutions?
How much effort do we intend to waste on such a clearly-defined non-
problem ?
Peter Alfke

Article: 132485
Subject: Re: FIFO verses RAMB
From: John_H <newsgroup@johnhandwork.com>
Date: Wed, 28 May 2008 14:44:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
Erik Anderson wrote:
> In the Xilinx Virtex 4 architecture, does anyone know when you
> instantiate a FIFO using the FIFO16 blocks does the FIFO use the
> RAMB16 block next to it for its memory, or does the FIFO16 has its own
> dedicated memory (thus leaving the RAMB16 free for other uses)?

The FIFO16:

  http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/v4lsc/v4lsc0092_83.html

uses dedicated logic to turn a BlockRAM into a FIFO, either
synchronous or asyncronous.  Using one of these large FIFOs will use a
BlockRAM.  Smaller FIFOs can be implemented in distributed logic,
however, leveraging the Shift Register memory mode of the LUTs for the
synchronous FIFO.  Many synthesizers will imply shift registers
properly if you design the synchronous FIFO to leverage the silicon
properly.  Async FIFOs are a little more difficult in distributed
memory and must use the dual-port mode but can work beautifully for
small FIFOs.

So how large are you going for?

Article: 132486
Subject: Re: Sequentially syncrhronous
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 28 May 2008 17:57:34 -0400
Links: << >>  << T >>  << A >>

"Peter Alfke" <peter@xilinx.com> wrote in message 
news:e3a18ba3-db21-498c-840a-3b36ce73246f@u12g2000prd.googlegroups.com...

> Is somebody trying to re-invent the wheel?

Most likely...but also most likely not in order to invent a better wheel but 
to learn.

> Haven't we been through this in a seemingly endless thread?

Yes

> Didn't I point out two perfect and compact solutions?

Others posted solutions as well, don't take all the credit.

> How much effort do we intend to waste on such a clearly-defined non-
> problem ?

If you feel that you're wasting your time, then perhaps you should choose 
not to do that.

KJ 



Article: 132487
Subject: Re: Software instabilities with EDK 10.01 and PPC405?!??!!!
From: Philipp Hachtmann <hachti@hachti.de>
Date: Thu, 29 May 2008 00:51:16 +0200
Links: << >>  << T >>  << A >>
Problem solved!

Ist was really a stack/heap insufficiency combined with a very little
programming error (Forgot a wait condition related to the Xilinx IIC 
driver) that caused my design go mad.
Now everything seems to be fine.

Thanks again,

Philipp :-)

Article: 132488
Subject: Re: Sequentially syncrhronous
From: "MikeWhy" <boat042-nospam@yahoo.com>
Date: Wed, 28 May 2008 18:10:13 -0500
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter@xilinx.com> wrote in message 
news:e3a18ba3-db21-498c-840a-3b36ce73246f@u12g2000prd.googlegroups.com...
On May 28, 1:12 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
Is somebody trying to re-invent the wheel?
Haven't we been through this in a seemingly endless thread?
Didn't I point out two perfect and compact solutions?
How much effort do we intend to waste on such a clearly-defined non-
problem ?

=========
It isn't so much the reinvention of the wheel, Peter, but learning to hammer 
and chisel the stone round. It should have been a short exercise, but there 
are timing conflicts where I expected none. Doesn't it behoove the student 
to find the flaws in his thinking and approach?

I thank you for your elegant solution, which I have put away for later 
study.

I don't know what I'm doing wrong, and why my solution is so susceptible to 
problems. Hence, the questions.

Regards,
Mike.


Article: 132489
Subject: Re: Xilinx LogicCore Direct Instantiation
From: krw <krw@att.bizzzzzzzzzz>
Date: Wed, 28 May 2008 19:45:53 -0400
Links: << >>  << T >>  << A >>
In article <OqSdnacY_bKfqqHVnZ2dnUVZ_tvinZ2d@lmi.net>, 
rgaddi@technologyhighland.com says...
> krw wrote:
> > Toolset: ISE/ModelSim_PE/VHDL 
> > 
> > I've been asked to modify one of my designs for another application 
> > so decided it was time to parameterize it as much of it as possible.  
> > I ran into a roadblock changing configuration of CoreGen devices, so 
> > was simply going to force the eventual user to go through the GUI 
> > for any modifications.  Then I RTFM.  ;-)
> > 
> > In the Comparator V9.0 Product Specification there an example of 
> > direct instantiation (Page 7), which looks like it'll save me a lot 
> > of headaches.  I can simply use the generics I already have to 
> > manipulate the core.  My problem is that ISE doesn't find the 
> > comparator in the library.  I've had the problem (with ModelSim) 
> > where the libraries change and I'm pointing to an old copy but I 
> > don't know where to tell ISE where the libraries are.  I've always 
> > used the GUI to generate cores before, but I really like the idea of 
> > direct instantiation.  I can make my designs far more flexible 
> > without a whole lot of work.  Anyone with a cluestick?
> > 
> > 
> 
> Any reason to not just infer the comparator?  VHDL generics make this 
> sort of thing a breeze.

Two things...  First, I want to walk before running.  I also need to 
manually instantiate BRAMs and it would be nice to ditch the GUI 
altogether.  It would make managing mu libraries through various 
core releases much simpler.  

Perhaps it's no longer true, but I found that the LogicCore devices  
were better optimized than the ones that were inferred from HDL.  
For equality, I'd just infer the thing and be done with it.  Long 
magnitude comparators can have significant delays.  At least that's 
what I've found in the past.  (UPDATE: I did a test and inferred the 
comparators and one level up, even and it still seemed to pass 
timing (10% buffer through PAR) with the widest compare I expect (32 
bits).  Perhaps I'll go this way for the comparator anyway.  It's 
simpler.)  

I don't need generic for the inferred comparator (other than the 
ones describing the busses that are already there).  ;-)

-- 
Keith

Article: 132490
Subject: Re: Sequentially syncrhronous
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 29 May 2008 12:35:02 +1200
Links: << >>  << T >>  << A >>
MikeWhy wrote:
> 
> "KJ" <kkjennings@sbcglobal.net> wrote in message 
> news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com...
> On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
> 
>> Sorry, Guys. We're not quite done yet with the quadrature encoder. I 
>> tried
>> to rewrite it as a synchronous process. The behavioral sim shows it 
>> working
>> as intended. The post-route sim and onboard test don't work. 'debouncing'
>> never changes state in the sim. The leds don't sequence when I twist the
>> magic knob.
>>
> 
> This is always a symptom of a timing problem.  In your particular case
> I suspect the timing of 'a' and 'b' relative to clk is not meeting the
> setup/hold time requirements of the device (from your report file).
> The signals 'a' and 'b' should be brought into only one flop, the
> output of that flop should be fed into a second flop, the output of
> that second flop can then be reliably used wherever you currently have
> 'a' and 'b'.
> 
> ===================
> 
> 'a' and 'b' are driven by a hand turned rotary encoder.
> 
> I tried buffering them into flops with concurrent statements, a_next and 
> b_next, and used a_next and b_next internally. This caused 'a' and 'b' 
> to not get routed at all, along with all logic associated with them. The 
> circuit was reduced to only those parts lighting the leds.

Then your code must have been suspect.

You should NEVER drive the Quad pins, into anything other than sampling
FF's (unless you are trying an async design :)

Only the outputs of sampled signals should be in your state flows.

> 
>>>>>>>>>>>>>>>
> 
> 
> 
>> Also, is there a way to tell XST to not treat reset as a clock? I haven't
>> fully read up on configuration, having spent way too much time on this
>> little time waster.
> 
> 
> What makes you think that it is using reset as a clock?
> 
> ======
> The synthesis report:
> 
> Number of GCLKs:                         2  out of     24     8%
> 
> ...
> 
> Clock Information:
> ------------------
> -----------------------------------+------------------------+-------+
> Clock Signal                       | Clock buffer(FF name)  | Load  |
> -----------------------------------+------------------------+-------+
> sys_rst_pin                        | IBUF+BUFG              | 1     |
> sys_clk_pin                        | BUFGP                  | 7     |
> -----------------------------------+------------------------+-------+
> 
> Asynchronous Control Signals Information:
> ----------------------------------------
> -------------------------------------------------------------+---------------------------+-------+ 
> 
> Control Signal                                               | Buffer(FF 
> name)           | Load  |
> -------------------------------------------------------------+---------------------------+-------+ 
> 
> sys_rst_pin                                                  | IBUF | 
> 5     |
> Inst_q_decode/a_prev_and0000(Inst_q_decode/a_prev_and00001:O)| 
> NONE(Inst_q_decode/b_prev)| 2     |
> Inst_q_decode/a_prev_and0001(Inst_q_decode/a_prev_and00011:O)| 
> NONE(Inst_q_decode/b_prev)| 2     |
> -------------------------------------------------------------+---------------------------+-------+ 
> 
> 
> I suppose if I understood what that said, a_prev_andxxxxx are the cause 
> of my difficulties.

Strange looking report, - Try re-targeting to a CPLD, and look at the 
report equations. CPLD reports are more readable as they have wider-and 
terms, and less tool generated nodes.

So, they are a good way to make sure you, and the tools, are on the 
'same page'!

-jg


Article: 132491
Subject: Re: Sequentially syncrhronous
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 29 May 2008 12:39:43 +1200
Links: << >>  << T >>  << A >>
MikeWhy wrote:

> On the clock rising edge:
>    Check for state change on 'a' if we're not debouncing.
>        If 'a' changed state, ignore further changes (debouncing).
>        If the change is a rising edge on 'a',
>            'b' is the direction of movement.
>            Increment or decrement the count accordingly.
>    Otherwise, we're already debouncing.
>        Clear debounce on the next 'b' change.
> 
> It would be more clear to restructure it explicitly as a FSM with the 2 
> states. I will do so.

This only counts once per 4 quadrants, or one quarter of the possible
count rate.
I presume that was your intention ?

-jg


Article: 132492
Subject: Re: Sequentially syncrhronous
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Thu, 29 May 2008 12:52:26 +1200
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> MikeWhy wrote:
> 
>>Sorry, Guys. We're not quite done yet with the quadrature encoder. I
>>tried to rewrite it as a synchronous process. The behavioral sim shows
>>it working as intended. The post-route sim and onboard test don't work.
>>'debouncing' never changes state in the sim. The leds don't sequence
>>when I twist the magic knob.
> 
> 
> I like Ray's process here:
> http://groups.google.com/groups/search?q=quadrature+resolver+single+process
> I've added an entity here:
> http://mysite.verizon.net/miketreseler/quad_encode.vhd
> RTL view looks good, but untested.

To me, both examples look to have an error, in confusing an edge with a 
direction.

See Peter/Ken's Tested example, for separate rotary_event, rotary_right 
code.

-jg



Article: 132493
Subject: Re: Sequentially syncrhronous
From: "KJ" <kkjennings@sbcglobal.net>
Date: Wed, 28 May 2008 20:52:42 -0400
Links: << >>  << T >>  << A >>

"MikeWhy" <boat042-nospam@yahoo.com> wrote in message 
news:Rpg%j.1342$iM3.234@flpi150.ffdc.sbc.com...
>
> "KJ" <kkjennings@sbcglobal.net> wrote in message 
> news:148a2566-df59-4dc1-9644-f231a378a9eb@t54g2000hsg.googlegroups.com...
> On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>>> Sorry, Guys. We're not quite done yet with the quadrature encoder. I 
>>> tried
>>> to rewrite it as a synchronous process. The behavioral sim shows it 
>>> working
>>> as intended. The post-route sim and onboard test don't work. 
>>> 'debouncing'
>>> never changes state in the sim. The leds don't sequence when I twist the
>>> magic knob.
>>
>>
>> This is always a symptom of a timing problem.  In your particular case
>> I suspect the timing of 'a' and 'b' relative to clk is not meeting the
>> setup/hold time requirements of the device (from your report file).
>> The signals 'a' and 'b' should be brought into only one flop, the
>> output of that flop should be fed into a second flop, the output of
>> that second flop can then be reliably used wherever you currently have
>> 'a' and 'b'.
>
> ===================
>
> 'a' and 'b' are driven by a hand turned rotary encoder.
>

Timing analysis is not about how often things change, but when do they 
change relative to whatever it is that samples them.  You have three 
asynchronous inputs to your design (rst, a, b).  What that means is that if 
I were to ask you when does rst change in relationship to the clock your 
answer would be I dunno (or something more grammatically correct).  The same 
would be true for 'a' and 'b'.

The problem is you then use these signals directly as inputs into logic that 
gets clocked.  The propogation delay from the input pin through whatever 
logic there is to EACH flip flop will be different so when the clock comes 
along some of the flops will see the 'new' value others will miss it.  On 
the next clock cycle, since some of the flops may have changed state, the 
net result of the logic may be different.  That's why you need to 
synchronize everything to the clock first and then only use the synchronized 
signals.  In your case, make some new signals like rst_sync, a_sync and 
b_sync where you bring rst, a and b in and perform no logic at all, just 
clock them into a flop (i.e. with a clocked process).

Now change your logic to use a_sync instead of 'a', b_sync instead of 'b' 
and rst_sync instead of 'rst'.  This means lines like this...
if (rst = '1') then
if (a /= a_prev) then
etc.

will change to this...
if (rst_sync = '1') then
if (a_sync /= a_prev) then
etc.

Make sure that the ONLY place you use 'rst', 'a', or 'b' is to generate 
'rst_sync', 'a_sync' and 'b_sync'.  Reset the temptation to violate this 
anywhere for any reason.

Simulate and make sure things still function.

> I tried buffering them into flops with concurrent statements, a_next and 
> b_next, and used a_next and b_next internally. This caused 'a' and 'b' to 
> not get routed at all, along with all logic associated with them. The 
> circuit was reduced to only those parts lighting the leds.
>

Well, for starters you can't buffer them into flops with concurrent 
statements unless you did this.
rst_sync <= rst when rising_edge(clk)
Usually one would do it like this
process(clk)
begin
  if rising_edge(clk) then
    rst_sync <= rst;
  end if;
end process;

You can of course simply add the "rst_sync <= rst;" statement to your 
clocked process if you prefer inside the "elsif (clk'event and clk = '1') 
then" portion.

Secondly, if things didn't get routed, it was because you didn't connect 
something up properly.  Had you simulated the design you would find that it 
wasn't working either.

>>>>>>>>>>>>>>>
>
>
>
>> Also, is there a way to tell XST to not treat reset as a clock? I haven't
>> fully read up on configuration, having spent way too much time on this
>> little time waster.
>
> What makes you think that it is using reset as a clock?
>
> ======
> The synthesis report:
>
> Number of GCLKs:                         2  out of     24     8%
>
> ...
>
> Clock Information:
> ------------------
> -----------------------------------+------------------------+-------+
> Clock Signal                       | Clock buffer(FF name)  | Load  |
> -----------------------------------+------------------------+-------+
> sys_rst_pin                        | IBUF+BUFG              | 1     |
> sys_clk_pin                        | BUFGP                  | 7     |
> -----------------------------------+------------------------+-------+
>

This is not a concern.  It is simply saying that it's using a buffer to 
drive the reset signal because it has a lot of internal loads, just like the 
clock does.  It's unfortunate that it says 'clock buffer' when it means 
something more like 'big honkin buffer that can drive a lot of loads'.

Kevin Jennings 



Article: 132494
Subject: Re: Sequentially syncrhronous
From: rickman <gnuarm@gmail.com>
Date: Wed, 28 May 2008 19:13:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 28, 12:10 pm, KJ <kkjenni...@sbcglobal.net> wrote:
> On May 28, 11:24 am, Brian Philofsky
>
> <brian.philofsky@no_xilinx_span.com> wrote:
> > KJ wrote:
> > > On May 28, 6:50 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote:
>
> > This very well could be a timing issue but another possible cause of
> > this could be the writing of simulatable code but not synthesizable
> > code.  Looking at the code, I see the signals a and b in the sensitivity
> > list of the process which could cause the else statement to get
> > evaluated asynchronously in simulation however for synthesis, the
> > sensitivity list is likely ignored (generally with a warning) and thus
> > processed differently.
>
> Having 'a' and 'b' in the sensitivity list is not the problem.  The
> structure of the code is
> process(...)
> begin
> if (rst = '1') then
>    ...assignements here
> elsif (clk'event and clk = '1') then
>    ...assignements here
> end if;
> end process;
>
> There are no assignments to anything outside of the if statement.
> That if statement is of the form for flops with async presets/resets.
> Having 'extra' signals in the sensitivity list will not result in any
> difference between simulation and synthesis.  If it does, then contact
> the synthesis tool provider and submit a bug report.

Not only is the a and b not a problem, the a in the sensitivity list
is *required* for proper simulation unless the simulator has the
smarts to fix problems with the sensitivity list.

Notice that there are assignments in the if (rst ='1') clause that
have a on the right hand side.  Since this is not in the clocked
portion of the process, this is a concurrent assignment and the
process must run when either rst or a change.


> > >> Also, is there a way to tell XST to not treat reset as a clock? I haven't
> > >> fully read up on configuration, having spent way too much time on this
> > >> little time waster.
>
> > I imagine you are referring to XST using a global buffer for the reset
> > signal.  In general this should not cause any issues and many times can
> > be the right thing to do but if you want to go to prevent that behavior,
> > tell XST you want an IBUF on the reset signal by adding the following
> > attribute:

If the reset signal is being run on a global clock line, it is because
your code does not allow the GSR to be used (a global net dedicated to
the reset function).  You are resetting to a signal value instead of a
fixed value, so the set/reset signals have to be brought out to the
routing matrix to accommodate that.  It is actually preferred to use
the clock nets for such a reset since your reset likely has a high
fanout and it will not be able to meet a fast timing spec any other
way.  This also saves a lot of routing resources if you have spare
clock lines.


> > >> Last, .... is this really worth pursuing? I've been programming for 25
> > >> years, and know that the greatest leassons come after the greatest pain. But
> > >> there's also good pain, and just senseless injury. Is this not a suitable
> > >> first Zen parable to contemplate? I'm goaded forward by the belief that
> > >> there's a good lesson on synchronous systems lurking as the punchline.
>
> > > The punchline might be static timing analysis.  Signals don't just
> > > 'happen' when you want them to, you need to guarantee by design that
> > > they arrive at the proper time relative to the clock.

Can you say what your clock rate is?  For the most part, speeds of
below 25 MHz are pretty easy to meet.  Speeds of 100 MHz are a lot
tougher.  Speeds in the middle depend on the logic and the density.
As you get above about 70% or 80% full, it gets harder to meet faster
timing.

The one problem that most newbies have, especially if they come from a
software orientation, is thinking of HDL as software.  HDL stands for
Hardware Description Language and that is how it works.  It describes
hardware.  If you try to write it like software, you most likely won't
care for the hardware that results, if it produces hardware at all.
Every construct I write I picture in terms of the hardware it will
generate as well as the behavior it has.

Rick

Article: 132495
Subject: Re: Sequentially syncrhronous
From: rickman <gnuarm@gmail.com>
Date: Wed, 28 May 2008 19:59:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 28, 8:39 pm, Jim Granville <no.s...@designtools.maps.co.nz>
wrote:
> MikeWhy wrote:
> > On the clock rising edge:
> >    Check for state change on 'a' if we're not debouncing.
> >        If 'a' changed state, ignore further changes (debouncing).
> >        If the change is a rising edge on 'a',
> >            'b' is the direction of movement.
> >            Increment or decrement the count accordingly.
> >    Otherwise, we're already debouncing.
> >        Clear debounce on the next 'b' change.
>
> > It would be more clear to restructure it explicitly as a FSM with the 2
> > states. I will do so.
>
> This only counts once per 4 quadrants, or one quarter of the possible
> count rate.
> I presume that was your intention ?

Yeah, that was what I saw too.  A quad decoded should be able to
increment on *each* edge of each signal.  Both rising and falling
edges have meaning and the direction is always indicated by the
combination of edge direction and state of the other signal.

I see the best approach as two state machines.  One is the debouncer
of *each* signal, a and b which also produces outputs for "edge of"
each signal.  The other is the quad decoder that has to consider the
inputs a, b, a edge and b edge.  Your combined state machine seems
awkward and I'm not even sure it works.  If you turn past a rising
edge on a, and then reverse, the same spot on the encoder will produce
a falling edge on a which is ignored.  It won't produce a rising edge
on a until you turn it back half a cycle.  If you don't reach that
half a cycle before reversing again and pass the same rising edge of a
it will count up a second time!  This is just plain wrong!  Consider
that the decoder has to distinguish eight different combinations.
There are four different points in time and two directions.

a  __1____2__++3++++4++__1____2__++3++++4++__1__
b  __1__++2++++3++__4____1__++2++++3++__4____1__

View the above in a fixed width font.  See how there are four
distinguishable states?  You need to detect the four states of the
encoder.  In any given state you will see a transition on one of the
two signals.  Which signal transitions tells you which direction you
are headed.

The point of a quad encoder is to make the presence and direction of
changes clearly distinguishable.  In fact, unless the bouncing is fast
compared to your clock rate, you don't even need to debounce the
encoder.  If you get two rising edges and a falling edge between, it
should count up twice and down once and automatically debounce!  Do
use a single FF for each signal a and b before you use them in the
FSM.  An async signal may be seen in different states by the multiple
FFs in a FSM.  That will result in very bad behavior.  Metastability
can also be an issue, but I expect this just won't be apparent in your
case. Still, even passing the signal through one FF will virtually
eliminate metastability for clock rates below 25 MHz unless you really
push the logic.  Metastability is removed by the slack time between
FFs.

I need to do my own work, but it is boring me at the moment.  I'm just
not quite interested enough to try to figure out the other problems in
your code... :^(  I was not in on the other thread I guess you
started, but it looks like there was no shortage of suggestions of how
to write this better.  If you were here, I would be happy to discuss
this with you, but writing is just not as much fun. (you wouldn't know
by the length of this post...)

Sometimes computer coding is a bit like writing (literary, that is).
Trying to fix something that is inherently bad does not really teach
anything.  Instead there are times you need to toss out what you have
done and consider the work of others.  If someone has given you code
or pseudo-code that should work, then you might want to try
implementing that.  I bet when you have something that works and you
understand it, you can better see the issues with your code.

Rick

Article: 132496
Subject: Re: HDL - simulation vs synthesis
From: jared.pierce@gmail.com
Date: Wed, 28 May 2008 20:25:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks for the help guys.  I made several changes and the problem
finally went away.  It works!  I still don't know why it wasn't
working so I plan to back up what I have and insert one test problem
at a time to see what happens(of the problems I fixed).  I still don't
get why the RTL schematic would bother to include a DFF where the Q
wasn't connected to anything.  It would have been just as good not to
include it.  Any hints on that one?

Article: 132497
Subject: Re: Sequentially syncrhronous
From: rickman <gnuarm@gmail.com>
Date: Wed, 28 May 2008 20:37:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
Now that I have looked at it, this seems so frigging simple that I am
going to try to write it on the fly!

right_way : process (clk, rst) begin
  if (rst = '1') then
    old_a <= '0';
    old_b <= '0';
    older_a <= '0';
    older_b <= '0';
    count <= "0101";
  elsif (rising_edge(clk)) then
    if (old_a /= older_a or old_b /= older_b) then -- detect an edge
      case ((older_a, older_b)) is -- not sure if this aggregate is
valid, you may need to make an assignment in the concurrent section
        when ("00") => if (old_a = '1') then count = count-1; else
count=count+1; end if;  -- state 1
        when ("01") => if (old_a = '1') then count = count+1; else
count=count-1; end if;  -- state 2
        when ("11") => if (old_a = '1') then count = count+1; else
count=count-1; end if;  -- state 3
        when ("10") => if (old_a = '1') then count = count-1; else
count=count+1; end if;  -- state 4
      end case;
    end if; -- edge detect
  end if; -- rst
end process right_way ;

I don't use the STD_LOGIC_UNSIGNED library.  It has been so long that
I don't even remember why.  I think it has to do with the inability to
use both signed and unsigned in the same code. I suggest that you use
numeric_std instead.  Declare your counter as unsigned instead of
SLV.

The only possible problem I see with this code is the startup.  I
didn't assign the registers the value of a and b on reset.  The reset
shown is a way to specify what the chip will do coming out of the
global reset from configuration.  If I want any other resets in the
system, I use synchronous resets.

  elsif (rising_edge(clk)) then
    if (sync_rst = '1') then
      old_a <= a;
      ...
    else
      -- state machine logic
    end if; -- sync_rst = '1'
  end if; -- rising_edge ...

This will give you your starting state so that the decoder does not
have to waste time synchronizing.  I thought that it might only take a
couple of clicks to get it sync'd without the reset to a and b, but it
is pathological and always remains unsync'd if started 90 degrees out
*and* it thinks it is rotating the wrong way.

Rick

Article: 132498
Subject: Are FPGAs headed toward a coarse granularity?
From: rickman <gnuarm@gmail.com>
Date: Wed, 28 May 2008 21:32:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
I was reading about the MathStar FPOA devices and I started thinking
about parallels between the architectural advances in CPUs compared to
FPGAs.  With the increases in speed with process refinements dropping
off in the current technologies, CPU makers have taken advantage of
the increased density to provide multiple CPUs rather than continually
increasing the clock rates.

FPGAs on the other hand, continue to increase density by making larger
versions of the same chips and trying to push speed as they go.  The
only exception to this is the way they have incorporated functions on
the chip that are not the basic building blocks.  I believe it started
with memory blocks.  Then multipliers were added.  Now there are a
number of different dedicated functional blocks that are available on
the high end FPGA devices.

So where is this headed now?  My understanding is that the FPOA was a
rather coarse grained architecture.  I also have the impression that
the company is not succeeding because of software issues, not any
inherent lacking in the devices or the architecture.  In fact, from
what I have read, a coarse grained architecture can provide a lot
faster processing and higher density than can a fine grained one
making the silicon cost a lot lower.

With the cost of gates dropping to such low levels, does it really
make sense to continue to provide fine grained devices which use so
much of the device for routing?  I don't remember who first told me,
"We sell you the routing and throw in the logic for free!"  A coarse
grained architecture should require much less of the programmable
routing giving you much more of the "free" logic.

It seems like the current FPGA devices are heading in the coarse
grained direction.  They just haven't cut the umbilical cord yet.
Most likely because that cord is rooted in the old software.  A coarse
grained architecture would need a doctor's slap on the behind for the
birth of new design tools.

So, are coarse grained architectures the way of FPGA... opps FPxA
devices in the near future?  Will the lowly LUT and FF be pushed into
the dark corners of the die in coming years?  I think it is not a
matter of if, just a matter of when and I think the when is soon!

Article: 132499
Subject: Re: asic gate count
From: Thomas Stanka <usenet_nospam_valid@stanka-web.de>
Date: Wed, 28 May 2008 22:17:43 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 28 Mai, 20:24, <vijayant.rutg...@gmail.com> wrote:
> I have a design on FPGA that is ready. However, we need to have some
> mapping from fpga design to asic. I know that this will not be
> accurate. But accuracy is not our concern right now. We just need
> upper bound.  Also, we are also looking for some IP Core for ASIC so
> that we can rough estimate.

Take the nuber of registers and combinatorial cells used for the fpga.
Start with the registers, inspect if you have register doubling in
synthesis for load balance and ask yourself if you need this register
doubling. In ASIC you have often load balancing with buffering.
For combinatorical logic you should have a look, what type of cells is
in your vendors library.
For a lot of technologies the tool will more likely use 3 input cells
instead of 4 input cells. This will roughly increase your
combinatorical cell count by 10%-30% (it depends on the design).
You should take into account, that you need to add something like 10%
buffering for global nets and timing correction that comes for free in
an fpga.

bye Thomas



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