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 37875

Article: 37875
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs - please respond???
From: Bret Wade <bret.wade@xilinx.com>
Date: Sat, 22 Dec 2001 11:05:32 -0700
Links: << >>  << T >>  << A >>
Hi Austin,

There is a Xilinx Answer Record that provides this information for Synplcity as
well as other synthesis vendors:

   http://support.xilinx.com/techdocs/12288.htm

This will result in IOB=TRUE attributes being passed through the edif file (or
.ngc for XST). If the IOB attributes exist and the register is eligible for an
IOB pack, it will be packed into the IOB with or without the use of the "-pr b"
switch during Map.

Because I am the 2nd-tier support person for Map issues, I have probably
debugged more Xilinx IOB packing issues than anyone. The Map support of IOB
packing has been solid since since we fixed the bug described in Xilinx Answer
9344 over a year ago in 3.1i SP1. I'm asked to debug a lot of "failed" cases
and they always turn out to be failing for one of the following reasons:

1. IOB=TRUE attribute not being set as expected.
2. An inversion exists that can not be supported by the hardware.
3. Fanout exists that can not be supported by the hardware.
4. A conflict in control signals exists that can not be supported by the
hardware.
5. And my personal favorite, the register is area constrained to a group of
slices.

Regards,
Bret

Austin Franklin wrote:

> Bret, I'm still waiting for an answer to this, would you  (or anyone who
> knows the answer) please respond...
>
> This was what I asked:
>
> Bret,
>
> Where are you assigning these attributes?  You said in the "front end
> tools", yet Synplcity has an "syn_useioff" that doesn't appear to
> matter...you still need the "-pr b" in the mapper.  According to the
> Synplicity docs, there is no "iob" attribute...  Are you talking about in a
> constraint file?  That's really got nothing to do with the synthesis front
> end tools...
>
> Austin


Article: 37876
Subject: How do i get rid of "Signal xx has a multisource" warning in Xilinx webpack ?
From: "Rob Finch" <robfinch@sympatico.ca>
Date: Sat, 22 Dec 2001 13:07:04 -0500
Links: << >>  << T >>  << A >>




Article: 37877
Subject: Beginners question: several circuits in one chip
From: marc@aargh.franken.de (Marc)
Date: 22 Dec 2001 18:39:04 GMT
Links: << >>  << T >>  << A >>
Hi.  I'm new to VHDL and FPGAs.  I use the Atmel FPSLIC starter kit with
Atmels System Designer 2.1.

I made two different designs that work on their own.  One is a counter,
the other one is a shifter.  Both are intended to be selected by the
microcontroller core of the FPSLIC with an IO select to transfer data
via the 8 bit data bus.

How do I combine both into one design?  When I connect microcontroller
pins I do have to select a top level entity and can only connect pins
to that.  But both of my designs are equally important, I have no top
level.

And how can I put the designs into two files?  I only managed to do
the synthesis when I described both in one file.


Are there any examples on how to combine several almost _independant_
logic circuits into one FPGA chip?  Mine don't share more than the
bus and the clock and certainly there is none that includes an
instance of the other one as part of it.


Marc.

-- 
Read about entire harddrive encryption for Win9x at http://secmbr.cjb.net

Article: 37878
Subject: Re: Kindergarten Stuff
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 22 Dec 2001 20:27:29 +0100
Links: << >>  << T >>  << A >>
"Bryan" <bryan@srccomp.com> schrieb im Newsbeitrag
news:3c235d4a$0$11078$724ebb72@reader2.ash.ops.us.uu.net...

> True, crying is easy.  The design is running at 200Mhz DDR.  As crappy as

Hmm, all these 16 independent clocks for the FIFOs run at this rate?  This
is no piece of cake.

--
MfG
Falk







Article: 37879
Subject: Re: How do i get rid of "Signal xx has a multisource" warning in Xilinx webpack ?
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Sat, 22 Dec 2001 20:02:16 -0000
Links: << >>  << T >>  << A >>
If you use VHDL, you could try redefining signal xx as std_ulogic.
The sim/syn will do the rest.


"Rob Finch" <robfinch@sympatico.ca> wrote in message
news:d34V7.34163$J%2.4658165@news20.bellglobal.com...
>
>
>



Article: 37880
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs - please respond???
From: "Austin Franklin" <austin@dark98room.com>
Date: Sat, 22 Dec 2001 16:56:52 -0500
Links: << >>  << T >>  << A >>
Bret,

Thanks for the reply, but I still believe we're not in sync.

The "syn_useioff" for Synplicity did not (or at least did not) work, I had
to use "pr-b" to get registers into IOBs.  I also believe a number of other
people have backed me up on this, saying they found the exact same thing.
It may very well be true that is is fixed on the current tools (and possibly
was fixed some time ago), I have not attempted to remove the "pr-b" from my
batch file.  Note, that the record you reference has a "last modified" date
of 10/16/01!

The second case you mention, 9344, states that the "pr-b" option WAS being
used, and it didn't work...I believe that is an entirely different issue
that I, and others, were describing.  The problem we were seeing was the
"use_synioff" was being ignored completely, and you HAD to use "pr-b" to get
registers into IOBs...and that worked.

Austin


"Bret Wade" <bret.wade@xilinx.com> wrote in message
news:3C24CB6C.9F063E3C@xilinx.com...
> Hi Austin,
>
> There is a Xilinx Answer Record that provides this information for
Synplcity as
> well as other synthesis vendors:
>
>    http://support.xilinx.com/techdocs/12288.htm
>
> This will result in IOB=TRUE attributes being passed through the edif file
(or
> .ngc for XST). If the IOB attributes exist and the register is eligible
for an
> IOB pack, it will be packed into the IOB with or without the use of the
"-pr b"
> switch during Map.
>
> Because I am the 2nd-tier support person for Map issues, I have probably
> debugged more Xilinx IOB packing issues than anyone. The Map support of
IOB
> packing has been solid since since we fixed the bug described in Xilinx
Answer
> 9344 over a year ago in 3.1i SP1. I'm asked to debug a lot of "failed"
cases
> and they always turn out to be failing for one of the following reasons:
>
> 1. IOB=TRUE attribute not being set as expected.
> 2. An inversion exists that can not be supported by the hardware.
> 3. Fanout exists that can not be supported by the hardware.
> 4. A conflict in control signals exists that can not be supported by the
> hardware.
> 5. And my personal favorite, the register is area constrained to a group
of
> slices.
>
> Regards,
> Bret
>
> Austin Franklin wrote:
>
> > Bret, I'm still waiting for an answer to this, would you  (or anyone who
> > knows the answer) please respond...
> >
> > This was what I asked:
> >
> > Bret,
> >
> > Where are you assigning these attributes?  You said in the "front end
> > tools", yet Synplcity has an "syn_useioff" that doesn't appear to
> > matter...you still need the "-pr b" in the mapper.  According to the
> > Synplicity docs, there is no "iob" attribute...  Are you talking about
in a
> > constraint file?  That's really got nothing to do with the synthesis
front
> > end tools...
> >
> > Austin
>



Article: 37881
Subject: Re: Beginners question: several circuits in one chip
From: Ray Andraka <ray@andraka.com>
Date: Sat, 22 Dec 2001 21:58:12 GMT
Links: << >>  << T >>  << A >>
You make a top level design that instantiates the two designs you have.  That
top level ties everything together into a common design, and will likely also
serve as your interface to the outside.

Marc wrote:

> Hi.  I'm new to VHDL and FPGAs.  I use the Atmel FPSLIC starter kit with
> Atmels System Designer 2.1.
>
> I made two different designs that work on their own.  One is a counter,
> the other one is a shifter.  Both are intended to be selected by the
> microcontroller core of the FPSLIC with an IO select to transfer data
> via the 8 bit data bus.
>
> How do I combine both into one design?  When I connect microcontroller
> pins I do have to select a top level entity and can only connect pins
> to that.  But both of my designs are equally important, I have no top
> level.
>
> And how can I put the designs into two files?  I only managed to do
> the synthesis when I described both in one file.
>
> Are there any examples on how to combine several almost _independant_
> logic circuits into one FPGA chip?  Mine don't share more than the
> bus and the clock and certainly there is none that includes an
> instance of the other one as part of it.
>
> Marc.
>
> --
> Read about entire harddrive encryption for Win9x at http://secmbr.cjb.net

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 37882
Subject: Re: How can I reduce Spartan-II routing delays to meet 33MHz PCI's Tsu < 7 ns requirement?
From: "Austin Franklin" <austin@dark98room.com>
Date: Sat, 22 Dec 2001 22:14:19 -0500
Links: << >>  << T >>  << A >>
Hi Carl,

> I'm pretty sure that if it were possible to make a Xilinx PCI IP core
without
> the special logic, Xilinx would have done it.  On the other hand, maybe
their
> new parts are enough faster than before that the special logic isn't
needed.

It IS possible to make a PCI "core" that does not NEED the special logic,
and have it be fully compliant at 33MHz, it does though ease the timing.

Also, to answer some of what Kevin wrote...you DO need to use some of the
raw PCI signals (as well as the same signals registered), I don't remember
which ones off the top of my head, but I can take a look at one of my PCI
cores if you are interested.

Regards,

Austin




Article: 37883
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs - please respond???
From: Bret Wade <bret.wade@xilinx.com>
Date: Sat, 22 Dec 2001 20:22:10 -0700
Links: << >>  << T >>  << A >>
Hello Austin,

Please see my comments below.

Regards,
Bret

Austin Franklin wrote:

> Bret,
>
> Thanks for the reply, but I still believe we're not in sync.
>
> The "syn_useioff" for Synplicity did not (or at least did not) work, I had
> to use "pr-b" to get registers into IOBs.  I also believe a number of other
> people have backed me up on this, saying they found the exact same thing.
> It may very well be true that is is fixed on the current tools (and possibly
> was fixed some time ago), I have not attempted to remove the "pr-b" from my
> batch file.  Note, that the record you reference has a "last modified" date
> of 10/16/01!

My expertise is limited to the Xilinx implementation tools. I don't know the
history of Synplicity's support of the syn_useioff attribute. What I can say
with certainty is that if the netlist comes into our tools with an IOB=TRUE
attribute, that it will be packed into an IOB if eligible, with or without the
-pr Map switch. That was my original claim before there was any mention of
Synplicty. There was a claim from Synplicty in this thread that the syn_useioff
attribute does work and results in an IOB=TRUE attribute. If this wasn't
working, I'd almost surely have heard about it in my work.

If you have a case that doesn't work, feel free to send it to me by mail after
Jan 2. (I'm currently monitoring my mail from a dialup connection in a vacation
home.)

>
>
> The second case you mention, 9344, states that the "pr-b" option WAS being
> used, and it didn't work...I believe that is an entirely different issue
> that I, and others, were describing.  The problem we were seeing was the
> "use_synioff" was being ignored completely, and you HAD to use "pr-b" to get
> registers into IOBs...and that worked.

I didn't mean to imply that this was a directly related issue, sorry for the
confusion. My point was only that this was the last known Map bug related to IOB
packing.

>
>
> Austin
>
> "Bret Wade" <bret.wade@xilinx.com> wrote in message
> news:3C24CB6C.9F063E3C@xilinx.com...
> > Hi Austin,
> >
> > There is a Xilinx Answer Record that provides this information for
> Synplcity as
> > well as other synthesis vendors:
> >
> >    http://support.xilinx.com/techdocs/12288.htm
> >
> > This will result in IOB=TRUE attributes being passed through the edif file
> (or
> > .ngc for XST). If the IOB attributes exist and the register is eligible
> for an
> > IOB pack, it will be packed into the IOB with or without the use of the
> "-pr b"
> > switch during Map.
> >
> > Because I am the 2nd-tier support person for Map issues, I have probably
> > debugged more Xilinx IOB packing issues than anyone. The Map support of
> IOB
> > packing has been solid since since we fixed the bug described in Xilinx
> Answer
> > 9344 over a year ago in 3.1i SP1. I'm asked to debug a lot of "failed"
> cases
> > and they always turn out to be failing for one of the following reasons:
> >
> > 1. IOB=TRUE attribute not being set as expected.
> > 2. An inversion exists that can not be supported by the hardware.
> > 3. Fanout exists that can not be supported by the hardware.
> > 4. A conflict in control signals exists that can not be supported by the
> > hardware.
> > 5. And my personal favorite, the register is area constrained to a group
> of
> > slices.
> >
> > Regards,
> > Bret
> >
> > Austin Franklin wrote:
> >
> > > Bret, I'm still waiting for an answer to this, would you  (or anyone who
> > > knows the answer) please respond...
> > >
> > > This was what I asked:
> > >
> > > Bret,
> > >
> > > Where are you assigning these attributes?  You said in the "front end
> > > tools", yet Synplcity has an "syn_useioff" that doesn't appear to
> > > matter...you still need the "-pr b" in the mapper.  According to the
> > > Synplicity docs, there is no "iob" attribute...  Are you talking about
> in a
> > > constraint file?  That's really got nothing to do with the synthesis
> front
> > > end tools...
> > >
> > > Austin
> >


Article: 37884
Subject: Re: How can I reduce Spartan-II routing delays to meet 33MHz PCI's Tsu <
From: Kevin Brace
Date: Sun, 23 Dec 2001 04:04:30 -0600
Links: << >>  << T >>  << A >>
Falk Brunner wrote:
> 
> "Kevin Brace" <kevinbraceusenetkillspam@hotmail.com.killspam> schrieb im
> Newsbeitrag news:3C202A1A.B51A40DD@hotmail.com.killspam...
> 
> > IRDY# (pin 23 and pin 24 respectively for Spartan-II PQ208), go through
> > a few levels of LUTs, and reach far away IOB output FF and tri-state
> ^^^^^^^^^^^^^^^^^^^^^^
> 
> I think THATs a good point to start optimization. HOW?
> 
> Ok, you have a decoding logic with lets say four levels of logic. IRDY#
> enter the FPGA, runs through the logic and reaches the input of an IOB FF.
> Now the propagation time through 4 levels of logic is too long, what to do?
> Lets say our logic has 10 input signals. One of them is IRDY. So this
> decoder can be repesented by a 1024 entry ROM right? If I dont have a 1024
> ENTRY ROM, You could use 2 512 entrys ROMS. The output is MUXed with IRDY#.
> So IRDY# has only to travel through 1 level of logic (timing analyzer calls
> this 3 levels, since it counts clock_2_out and setup as seperate levels)
> Got my point?
> 
> --
> MfG
> Falk


        Perhaps it is because of the synthesis tool I used (XST that
came with ISE WebPack 4.1) doesn't take advantage of Virtex
architecture's F6MUX multiplexer (uses one whole CLB (four 4-input LUTs)
that can implement an 8:1 multiplexer or a 19-input one big LUT), or
because using  the F6MUX multiplexer isn't any better improving gate
delay compared to using smaller regular 4-input LUTs, and connecting
them together, I haven't been able to use this F6MUX multiplexer.
In Map, there is an option to allow F6MUX to be considered during Map,
but that didn't seem take advantage of F6MUX either for the signal path
I was having problems (a signal path starting from FRAME# or IRDY# to
AD[31:0]).
Some non-critical paths seemed to use this F6MUX multiplexer.
I personally find your suggestion hard to implement with Xilinx or
Altera FPGAs considering that these FPGAs use 4-input LUTs.
Perhaps, an FPGA with a wider input LUT or CPLDs might do a better job.
I guess that is why some people say CPLDs are better for a state machine
design than FPGAs.
        I finally figured out a way to reduce the levels of logic by
eliminating a lot of "if" conditional statements (they were nested "if"
statements) before a data transfer to AD[31:0], and that reduced the
worst levels of logic from 6 levels (4 levels of LUTs) down to 5 levels
(3 levels of LUTs) for a signal path starting from FRAME# or IRDY# to
AD[31:0].
I am still trying to reduce that further down to 4 levels (2 levels of
LUTs) through modifying my RTL code.



Thanks,



Kevin Brace (don't respond to me directly, respond within the newsgroup)

Article: 37885
Subject: Re: How can I reduce Spartan-II routing delays to meet 33MHz PCI's Tsu <
From: Kevin Brace
Date: Sun, 23 Dec 2001 04:10:26 -0600
Links: << >>  << T >>  << A >>
Eric Crabill wrote:
> 
> Hi,
> 
> Have you considered changing your logic design?  I can't say
> for sure from reading your timing report, but it looks like you
> are using FRAME# and IRDY#, through some combinational logic,
> to enable the output flip flops for the AD bus.
> 

        Yes, FRAME# and IRDY# are both being evaluated in a "if"
conditional statement in Verilog.
From various suggestions I got from people who gave me their opinions in
this newsgroup, they were saying that I wasn't using registered input
enough, so I modified my code to take advantage of registered inputs in
situations where looking at the raw (unregistered) wasn't a mandatory
like during a Configuration cycle or a single transfer.
That seemed to improve the timing scores a lot, but the worst levels of
logic was still around 6 which means 4 levels of LUTs.


> I can imagine several places where you would do this; one is
> the logic that clocks out the address for your initiator when
> the bus is idle and you have GNT#.  This would clock out the
> address for the address phase(s).
> 

        Actually, mine isn't even there yet . . .
Because I wanted to get my PCI IP core to meet the 33MHz PCI timings
before I add more stuff, I haven't added the initiator feature yet.
I should be able to do so soon after I get the timings right.


> You can eliminate this path entirely by continually clocking
> out an address, even if it is invalid, because that address
> will not be driven on the bus (i.e. it doesn't matter what is
> in the output flops if the tristate lines are high...)
> 
> I prefer to think of this problem (the one of the output clock
> enables for the data path) as "When do I want to HALT outgoing
> data?" instead of trying to solve the more natural problem of
> when you should actually be enabling it.  Use the fact that
> the datapath will be tristated to your advantage.
> 
> You will still have to solve the problem of when to turn off
> the tristates, though.
> 
> Eric
>

        After using registered inputs for all I can think of (or all I
can reasonably implement without too much change to my code), and didn't
see the worst levels of logic not dropping for AD[31:0]'s output FF (use
of registered input reduced the levels of logic for AD[31:0]'s tri-state
control FF), I started to think what kind of bus cycle will take inputs
from FRAME# and IRDY# unregistered in a target mode, goes through LUTs,
and ends up at AD[31:0]'s output FF.
I found that in my code, during a target burst read, the code first
checks for the end of a burst cycle, checks for target abort request
from the user side, checks for disconnect request from the user side,
and finally data gets transferred from the user side to AD[31:0].
This whole process of checking status of various signals was implemented
in nested "if" statements, and because of that the synthesis tool was
creating a priority encoder (which is not synthesis tool's fault in any
way. It is the designer's fault.), which is often recommended to avoid
if possible.
Following your suggestion that unconditionally transferring data to an
output FF when the output is tri-stated will not cause any harm, I
rewrote the code so that the user supplied data will be transferred 
to AD[31:0] output FF virtually unconditionally whether or not the end
of a burst transaction is reached, a target abort is requested, or a
disconnect is requested.
As a result of that for a signal path starting from FRAME# or IRDY# to
AD[31:0] the worst levels of logic dropped from 6 levels to 5 levels (4
levels to 3 levels of LUTs), and that also reduced the gate and routing
delay by clearly noticeable amount.
I guess my goal now is to further reduce the worst levels of logic down
to 4 (2 levels of LUTs).




Thanks,




Kevin Brace (don't respond to me directly, respond within the newsgroup)

Article: 37886
Subject: THE SIGNAL LIST IS NOT AVAILABLE TO SIMULATE
From: wacky_me@rediffmail.com (freny)
Date: 23 Dec 2001 02:25:38 -0800
Links: << >>  << T >>  << A >>
I am using xilinx fs-2.1. In simulation I need to select the signals from the 
signal menu. I am unable to add the signals as no signals are shown in the ADD 
SIGNALS menu.
Can anyone help me in this respect

u can get me on wacky_me@xyxrediffmail.com    --remove xyz

Article: 37887
Subject: no net attached to set reset cell
From: wacky_me@rediffmail.com (freny)
Date: 23 Dec 2001 04:00:27 -0800
Links: << >>  << T >>  << A >>
hey,
I am using xilinx 2.1 . I  had the warning : no net attached to the
set reset
pin . 

i had targeted my vhdl code on xilinx 3000 series chipset . when i
targeted it on virtex I din get this warning . Can anyone enlighten me
on this.
regards

Article: 37888
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: hamish@cloud.net.au
Date: 23 Dec 2001 12:45:19 GMT
Links: << >>  << T >>  << A >>
Austin Franklin <austin@darkroom98.com> wrote:
> If you read what I wrote in my reply, you would note that I mentioned the
> syn_useioff "attribute" and also said that you still need the "pr -b"
> option, as just the attribute alone does not put the FFs in the IOBs...at
> least in the tool set I have been using...

If you use '-pr b' you don't need to use any Synplify IO attributes.

However you may have to use other attributes (eg syn_preserve) to
stop Synplify doing things that will prevent Xilinx MAP from putting
the flip flops in the IOBs. eg if two pins are driven with the same
signal, you need replicated flip-flops, and you need to syn_preserve
them to stop Synplify ripping them out.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 37889
Subject: Does the core or Xilinx Core Generator support timing-simlulation?
From: "deerlux" <deerlux@hotmail.com>
Date: Sun, 23 Dec 2001 21:31:06 +0800
Links: << >>  << T >>  << A >>
I generated a FIR core using the Xilinx Core Generator.When I used the
behavior module to do functional simulation,it's OK.The behavior module uses
the "mif"(Memory Initialization File) file.When I did timing simulation
after implemention,the result was not correct.Is the "mif" file usable to do
timing-simulation? I use the Aldec Active-HDL to simulate.I want to know if
the core support timing simulation.Why is my simulation result not correct?
Who can tell me?Thank you!
Deerlux White.



Article: 37890
(removed)


Article: 37891
Subject: Re: Kindergarten Stuff
From: Ed Ngai <engai@sprintmail.com>
Date: Sun, 23 Dec 2001 17:18:14 GMT
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> This is a friendly and helpful newsgroup, but let's make sure that it does not
> get abused.

All depends on who's definition of what 'abuse' is.

> Lots of textbooks explain how to divide by a power of 2, where the remainder is,
> and how you sign-extend the MSB. Explaining that is not the purpose of this
> newsgroup.

I'm not a hot shot FPGA user yet.  In fact it took me 4 to 6 months to find
out how to do a 4 to 1 multiplexer.  I had to go to 2 book stores, look
all over the web.  Sent email to Xilinx.  I'm not going to school, but I want
to learn how to work w/ FPGAs.  I finally bought 2 books, The VHDL handbook and
VHDL.

If it's in a book somewhere, then how about posting these book references?

Remember you have been doing this for a long time and I'm reading a chapter
maybe every month ?

 
> Let's use our "bandwidth" for more complex and perhaps controversial questions
> that are not explained in textbooks and data books.
> Peter Alfke, Xilinx Applications

How do I get the Foundation CDs from Xilinx?

Article: 37892
Subject: Re: Default Should Be "Inputs and Outputs" For IOBs - please respond???
From: "Austin Franklin" <austin@dark98room.com>
Date: Sun, 23 Dec 2001 13:08:44 -0500
Links: << >>  << T >>  << A >>
Hi Bret,

> My expertise is limited to the Xilinx implementation tools. I don't know
the
> history of Synplicity's support of the syn_useioff attribute. What I can
say
> with certainty is that if the netlist comes into our tools with an
IOB=TRUE
> attribute, that it will be packed into an IOB if eligible, with or without
the
> -pr Map switch. That was my original claim before there was any mention of
> Synplicty.

The Synplicity tools have an attribute "syn_useioff" and that's really all
that a Synplicity user SHOULD care about if they want to pack their FFs into
IOBs, IMO, as it should add the correct EDIF attribute to the output file.
Yes, I know that I can use "xc_props" in Synplify to try to pass any
attribute to the back end tools, but I should not have to do that if
"syn_useioff" is supposed to do this, and is working correctly.  In order to
use the "IOB=TRUE" attribute, I would have to put it on every IO pin I want
packed.  That is certainly a lot more time and effort than checking a box to
use "syn_useioff" or putting "pr-b" in the make file.

> There was a claim from Synplicty in this thread that the syn_useioff
> attribute does work and results in an IOB=TRUE attribute. If this wasn't
> working, I'd almost surely have heard about it in my work.

Well, I assure you, it was not passing "IOB=TRUE" through to the .EDF file
at one time (and that time frame would be last year at the least, I can not
tell you what revision of the tools though, possibly Synplify 5).  That is
why I had to add the "pr-b" to my batch file to get the FFs into the IOBs.
The new tools appear to put the correct construct, which is "(property IOB
(string "TRUE"))" in the EDIF file now, so you are correct, now that
Synplify appears to pass the attribute correctly, I do not need the "pr-b"
in my batch file.

In reality, the only way one would know if it was working or not would be to
either miss timing...or to bring up the FPGA Editor (or read the EDIF file),
and most people just don't bring up the FPGA editor and look at these
things.  My point is, most people do not check their designs using FPGA
Editor (or read their EDIF files), so they would not know if their FFs were
being packed into IOBs or not.

Another thing along the initial point Simon was making, I just visited a
client in NH who was not making timing, and I asked them if they "allowed"
the packing of the FFs into IOBs, at which I got a very puzzled look, and
they said they had no idea that it was something they HAD to do
intentionally to get the tools to do this.  One more good reason why it
should default TO on, not off.  I also believe you will find more people do
want their FFs placed in the IOBs than don't.

Austin




Article: 37893
Subject: Re: A ram wish
From: "stefaan vanheesbeke" <stefaan.vanheesbeke@pandora.be>
Date: Sun, 23 Dec 2001 18:44:00 GMT
Links: << >>  << T >>  << A >>

"stefaan vanheesbeke" <stefaan.vanheesbeke@pandora.be> schreef in bericht
news:TaNU7.2090$Fe3.175@afrodite.telenet-ops.be...
> I wish the same thing as you do, and for the same reason...
>
> I think altera has a solution for this, but the use of their blockrams is
> not so clear documented as from Xilinx.
>

1. When usign xilinx components block memory :

    Read datasheet, look at the library description of the differtn blocks
you want to use, impelment in e.g. Verilog the combinations you want

2. When using Altera :

    Stop reading the manual about the possible things you can do with the
RAM blocks
    Don't try to understand the different library components
    Try to use the megawizard to get a solution fast and easy, but don't
expect to know how it is really implemtneted.


Both ways work for the people that don't bother "the" fastest and/or "the"
smallest solution. If you want to get more out of it, Xilinx does a nicer
job.

You can see also the difference if you want to look at the chip, Xilinx has
its chipviewer, where you can inspect every connection and internal
structure. This can be quite usefull when starting with new devices and
features. Altera has also a kind of chipviewer, but only with coloured
blocks and rast nest connections (or is there a feature in the quartus II
software that I didn't discovered yet?)


I can't wait until Xilinx comes with a nice and smooth solution for the
Microblaze. Here Altera has a somewhat better solution.


Stefaan





Article: 37894
Subject: Re: Defauolt Should Be "Inputs and Outputs" For IOBs
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 23 Dec 2001 19:05:29 +0000
Links: << >>  << T >>  << A >>


hamish@cloud.net.au wrote:

> Austin Franklin <austin@darkroom98.com> wrote:
> > If you read what I wrote in my reply, you would note that I mentioned the
> > syn_useioff "attribute" and also said that you still need the "pr -b"
> > option, as just the attribute alone does not put the FFs in the IOBs...at
> > least in the tool set I have been using...
>
> If you use '-pr b' you don't need to use any Synplify IO attributes.
>
> However you may have to use other attributes (eg syn_preserve) to
> stop Synplify doing things that will prevent Xilinx MAP from putting
> the flip flops in the IOBs. eg if two pins are driven with the same
> signal, you need replicated flip-flops, and you need to syn_preserve
> them to stop Synplify ripping them out.
>
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

That's one of the ``Stop Synplify breaking the IOB packing rules'' things in my
bag of tricks. Here's a couple of other gotchas I've come across:

o Lets say I have a 72-bit bi-dir data bus registered in both directions on and
the FFs (for reasons known only to me) have e.g sync resets driven from a
common source. Synplify will say "Uh-oh the fanout is greater than the default
syn_maxfan''. It will then duplicate the FF or LUT driving the reset line.
Having done that it will then allocate the duplicated signals randomly among
the 144 data bus FFs so there's no guarantee that any input/output pair shares
the same reset signal => broken packing rule.

o A more subtle variant of the previous goes like this: My bi-dir registered
signal doesn't, at HDL level, have a reset in either direction but post-synth
the output side can end up with one. Here's how:
The last logic stage feeding the output FF looks like this:

       signalA & !signalB

Synplify says "Hey! that's just like what a sync reset does" and puts signalA
on the `D' input and uses signalB as a sync reset. Two fixes are possible: Use
a syn_keep on the last stage (didn't work for Synplify 5.0.? but I think it
does now) or put a dummy async reset on both the in & out FFs.

o I drive my PCI IRDY signal direct & registered from the PCI master state
machine and, again at HDL level, I make sure that its not used as feedback
anywhere. However the IRDY signal basically turns on in one state, waits until
the last data cycle, then turns off. After optimisation Synplify produces a
synthesis that at HDL level would look like:

always @(posedge PCIclock)
    if (!PCIIRDY)
        PCIIRDY <= IRDY_on_State ? 1 : 0;
    else
        PCIIRDY <= IRDY_off_State ? 0 : 1;

or some such. So I've got feedback when I was being very careful to avoid it.
This one seems to turn up all over the place and but can be countered by ad hoc
variants of the ``duplicate FF'' trick Hamish mentioned.



Article: 37895
Subject: Re: Default Should Be "Inputs and Outputs" For IOBs - please respond???
From: Ray Andraka <ray@andraka.com>
Date: Sun, 23 Dec 2001 19:14:22 GMT
Links: << >>  << T >>  << A >>
You can also put a user attribute (attribute IOB:string; attribute IOB of FF1:label
is "TRUE";)  on the flip flop if it is instantiated in Synplicity, which get
attached to the instance, will work on any synthesizer that supports user attributes
and avoids the "hare today goon tomorrow" nature of the vendor specific attributes.

Bret Wade wrote:

> Hello Austin,
>
> Please see my comments below.
>
> Regards,
> Bret
>
> Austin Franklin wrote:
>
> > Bret,
> >
> > Thanks for the reply, but I still believe we're not in sync.
> >
> > The "syn_useioff" for Synplicity did not (or at least did not) work, I had
> > to use "pr-b" to get registers into IOBs.  I also believe a number of other
> > people have backed me up on this, saying they found the exact same thing.
> > It may very well be true that is is fixed on the current tools (and possibly
> > was fixed some time ago), I have not attempted to remove the "pr-b" from my
> > batch file.  Note, that the record you reference has a "last modified" date
> > of 10/16/01!
>
> My expertise is limited to the Xilinx implementation tools. I don't know the
> history of Synplicity's support of the syn_useioff attribute. What I can say
> with certainty is that if the netlist comes into our tools with an IOB=TRUE
> attribute, that it will be packed into an IOB if eligible, with or without the
> -pr Map switch. That was my original claim before there was any mention of
> Synplicty. There was a claim from Synplicty in this thread that the syn_useioff
> attribute does work and results in an IOB=TRUE attribute. If this wasn't
> working, I'd almost surely have heard about it in my work.
>
> If you have a case that doesn't work, feel free to send it to me by mail after
> Jan 2. (I'm currently monitoring my mail from a dialup connection in a vacation
> home.)
>
> >
> >
> > The second case you mention, 9344, states that the "pr-b" option WAS being
> > used, and it didn't work...I believe that is an entirely different issue
> > that I, and others, were describing.  The problem we were seeing was the
> > "use_synioff" was being ignored completely, and you HAD to use "pr-b" to get
> > registers into IOBs...and that worked.
>
> I didn't mean to imply that this was a directly related issue, sorry for the
> confusion. My point was only that this was the last known Map bug related to IOB
> packing.
>
> >
> >
> > Austin
> >
> > "Bret Wade" <bret.wade@xilinx.com> wrote in message
> > news:3C24CB6C.9F063E3C@xilinx.com...
> > > Hi Austin,
> > >
> > > There is a Xilinx Answer Record that provides this information for
> > Synplcity as
> > > well as other synthesis vendors:
> > >
> > >    http://support.xilinx.com/techdocs/12288.htm
> > >
> > > This will result in IOB=TRUE attributes being passed through the edif file
> > (or
> > > .ngc for XST). If the IOB attributes exist and the register is eligible
> > for an
> > > IOB pack, it will be packed into the IOB with or without the use of the
> > "-pr b"
> > > switch during Map.
> > >
> > > Because I am the 2nd-tier support person for Map issues, I have probably
> > > debugged more Xilinx IOB packing issues than anyone. The Map support of
> > IOB
> > > packing has been solid since since we fixed the bug described in Xilinx
> > Answer
> > > 9344 over a year ago in 3.1i SP1. I'm asked to debug a lot of "failed"
> > cases
> > > and they always turn out to be failing for one of the following reasons:
> > >
> > > 1. IOB=TRUE attribute not being set as expected.
> > > 2. An inversion exists that can not be supported by the hardware.
> > > 3. Fanout exists that can not be supported by the hardware.
> > > 4. A conflict in control signals exists that can not be supported by the
> > > hardware.
> > > 5. And my personal favorite, the register is area constrained to a group
> > of
> > > slices.
> > >
> > > Regards,
> > > Bret
> > >
> > > Austin Franklin wrote:
> > >
> > > > Bret, I'm still waiting for an answer to this, would you  (or anyone who
> > > > knows the answer) please respond...
> > > >
> > > > This was what I asked:
> > > >
> > > > Bret,
> > > >
> > > > Where are you assigning these attributes?  You said in the "front end
> > > > tools", yet Synplcity has an "syn_useioff" that doesn't appear to
> > > > matter...you still need the "-pr b" in the mapper.  According to the
> > > > Synplicity docs, there is no "iob" attribute...  Are you talking about
> > in a
> > > > constraint file?  That's really got nothing to do with the synthesis
> > front
> > > > end tools...
> > > >
> > > > Austin
> > >

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 37896
Subject: Re: Kindergarten Stuff
From: Ray Andraka <ray@andraka.com>
Date: Sun, 23 Dec 2001 19:24:24 GMT
Links: << >>  << T >>  << A >>
This is part of the problem.  Too many people are "learning" hardware design and VHDL
at the same time.  I am firmly of the opinion that folks need a solid digital hardware
background before learning VHDL.  Learning both at the same time leads to a host of
design problems caused by not understanding how the VHDL code is mapped into hardware,
as well as the inevitable timing problems that come up with code written as though it
was for a software target.  FPGA design is digital hardware design no matter what kind
of fancy tools you put in front of it.  If you don't design with hardware in mind,
you'll soon find out about it in the lab.

Ed Ngai wrote:

> I'm not a hot shot FPGA user yet.  In fact it took me 4 to 6 months to find
> out how to do a 4 to 1 multiplexer.  I had to go to 2 book stores, look
> all over the web.  Sent email to Xilinx.  I'm not going to school, but I want
> to learn how to work w/ FPGAs.  I finally bought 2 books, The VHDL handbook and
> VHDL.
>
> If it's in a book somewhere, then how about posting these book references?
>
> Remember you have been doing this for a long time and I'm reading a chapter
> maybe every month ?
>
>
> > Let's use our "bandwidth" for more complex and perhaps controversial questions
> > that are not explained in textbooks and data books.
> > Peter Alfke, Xilinx Applications
>
> How do I get the Foundation CDs from Xilinx?

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 37897
Subject: Re: Kindergarten Stuff
From: Ed Ngai <engai@sprintmail.com>
Date: Sun, 23 Dec 2001 23:27:09 GMT
Links: << >>  << T >>  << A >>
But for many years all I ever dealt w/ was TTL, CMOS, ECL, GALs, some linear.  
And for maybe 16 years I 'never' touched upon a need for implementing FPGAs,
using design tools, etc.  Because of a jelly doughnut in 1994 I went into a
Computer Literacy bookstore on Steven Creek and bought the FPGA Workbook by
Dave Bout, Xess Engr.  My 1st experience w/ an Intel FPGA, which Intel
obsoleted. 
I don't have a stacked bookshelf for FPGA written material.  I say if it's in 
a book somewhere, then post the book reference.  Is it that big of a deal to
post
a reference?


Ray Andraka wrote:
> This is part of the problem.  Too many people are "learning" hardware design and VHDL
> at the same time.  I am firmly of the opinion that folks need a solid digital hardware
> background before learning VHDL.  Learning both at the same time leads to a host of
> design problems caused by not understanding how the VHDL code is mapped into hardware,
> as well as the inevitable timing problems that come up with code written as though it
> was for a software target.  FPGA design is digital hardware design no matter what kind
> of fancy tools you put in front of it.  If you don't design with hardware in mind,
> you'll soon find out about it in the lab.

 
> Ed Ngai wrote:
 
> > I'm not a hot shot FPGA user yet.  In fact it took me 4 to 6 months to find
> > out how to do a 4 to 1 multiplexer.  I had to go to 2 book stores, look
> > all over the web.  Sent email to Xilinx.  I'm not going to school, but I want
> > to learn how to work w/ FPGAs.  I finally bought 2 books, The VHDL handbook and
> > VHDL.

> > If it's in a book somewhere, then how about posting these book references?

> > Remember you have been doing this for a long time and I'm reading a chapter
> > maybe every month ?

> > > Let's use our "bandwidth" for more complex and perhaps controversial questions
> > > that are not explained in textbooks and data books.
> > > Peter Alfke, Xilinx Applications
> > How do I get the Foundation CDs from Xilinx?

> --Ray Andraka, P.E. , President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com  ,  http://www.andraka.com

Article: 37898
Subject: Re: THE SIGNAL LIST IS NOT AVAILABLE TO SIMULATE
From: ZhengLin <zdzlin@163.com>
Date: Sun, 23 Dec 2001 19:28:06 -0800
Links: << >>  << T >>  << A >>
Because Foundation do some optimize on your design, if it think a Signal or a port have no effection on the output, then the resourse about this part of design will be removed, so if you want to see a signal, you may use it as a output port!

Article: 37899
Subject: where can I find a indepth manual about place and route in Quartus II
From: shengyu_shen@hotmail.com (ssy)
Date: 23 Dec 2001 19:29:33 -0800
Links: << >>  << T >>  << A >>
Hi everyone

where can I find a indepth manual about place and route in Quartus II?



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