Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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... > > AustinArticle: 37876
Article: 37877
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.netArticle: 37878
"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 FalkArticle: 37879
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
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
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: 37882Hi 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, AustinArticle: 37883
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
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
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: 37886I 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 xyzArticle: 37887
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. regardsArticle: 37888
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
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
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
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. AustinArticle: 37893
"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
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
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
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: 37897But 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.comArticle: 37898
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
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:
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