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
On Apr 30, 7:22=A0am, n...@puntnl.niks (Nico Coesel) wrote: > Now imagine a 32 and/or 64 pin QFN device with an ARM core, a 50k > Spartan 3 like FPGA fabric some ram and some flash. Price around $3 in > large quantities and available from every street corner (Digikey, > Farnell, RS-components, etc). Such a device would open a whole new > world. That's not really Xilinx's space, AND such a device still has to compete with any EXISTING PLD+uC solution. So claims of a 'whole new world' are excessive, as there are solutions now, and have been for years. Other players have more chance of approaching some of your wishlist, with Cypress and Actel sampling silicon. (& Atmel have a mask solution, if your volumes are enough) However, the big issue remains PRICE, with neither company coming anywhere near your price point!! That's been the historical failing of previous players in this space too... -jgArticle: 147526
-jg <jim.granville@gmail.com> wrote: >On Apr 30, 7:22=A0am, n...@puntnl.niks (Nico Coesel) wrote: >> Now imagine a 32 and/or 64 pin QFN device with an ARM core, a 50k >> Spartan 3 like FPGA fabric some ram and some flash. Price around $3 in >> large quantities and available from every street corner (Digikey, >> Farnell, RS-components, etc). Such a device would open a whole new >> world. > > That's not really Xilinx's space, AND such a device still has to >compete with any EXISTING PLD+uC solution. > > So claims of a 'whole new world' are excessive, as there are >solutions now, and have been for years. > > Other players have more chance of approaching some of your wishlist, >with Cypress and Actel sampling silicon. >(& Atmel have a mask solution, if your volumes are enough) > > However, the big issue remains PRICE, with neither company coming >anywhere near your price point!! > > That's been the historical failing of previous players in this space >too... So there is a lot to be won here. I'm sure a market can be created. Just look at how all low-cost scopes are built. Just one FPGA (usually Altera) with their NIOS processor embedded runs the entire show. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147527
On 28 Apr., 20:29, austin <aus...@xilinx.com> wrote: > Nico, > > How many will you buy? =A0How many will everyone buy? > > Putting anything in an FPGA device has to be backed by 1+ =A0billion ($) > in 2+ years for the family ... or I can't even afford to get a water > glass at the table in the marketing restaurant. > > Mask sets at 22nm, and development costs, are completely out of this > world. =A0We may be making a FPGA device that can be programmed to do > what you want, but we still have to serve the broadest market > possible, so we can afford to do it at all, and still make a profit > (reasonable ROI). This is true if you think about adding an extra device with that feature while still offering devices without the feature. If the added feature is small compared to the overal size of the FPGA the cost analysis changes if you add it to all devices (possible starting from a certain size). + there is no added mask cost 0 there is a small increase in device cost 0 a reduction in yield could be covered by selling failing devices as not having the feature - there is added risk of a respin because the complexity increases - there is added engineering cost in software and hardware for the added feature I do not believe that you need billions in market to cover a decision like this and that probably is why xilinx keeps adding features to their devices. BTW: I really would like to see JTAG signal integrity monitoring on all pins: http://dspace.mit.edu/bitstream/handle/1721.1/41609/216829581.pdf This adds virtually no real estate to the chip and every high speed board designer will shout "hurray" and jump into the air a couple of times. Regards, KoljaArticle: 147528
Am Wed, 28 Apr 2010 12:12:48 +0100 schrieb Brian Drummond <brian_drummond@btconnect.com>: > On Wed, 28 Apr 2010 00:12:05 +0200, Martin Br=FCckner <bj2spam@alice-dsl.= net> > wrote: >=20 > >Am Tue, 27 Apr 2010 11:17:03 +0100 > >schrieb Brian Drummond <brian_drummond@btconnect.com>: > > > >> On Tue, 27 Apr 2010 10:03:34 +0200, Martin Br=FCckner > >> <bj2spam@alice-dsl.net> wrote: >=20 > >> >> > (*linux)(); > >> >>=20 > >> >> With the assumption that data pointers can be properly > >> >> cast to function pointers, that line should jump to=20 > >> >> location 0x4002b4 and start executing the code there. >=20 > >> Xilinx example code typically has boilerplate to do things like > >> invalidate caches and set up interrupt state before handing over to > >> "real" code. >=20 > >> Have you covered these bases in your own code? > > > >When I started with this project I was sure that Linux invalidates > >caches and sets up the interrupt state a >=20 > You are probably correct on interrupts, but on caches... >=20 > >Anyway, all I tried out yet was disabling the cache but that did not > >help.=20 >=20 > That would do it. Lets Linux invalidate, then enable them when safe. > If that's not your problem, then I can't help further. >=20 > The only other gotchas I remember are: >=20 > (1) the interrupt vector table has to be on a 64k boundary. The tools let= you > put it anywhere but the bottom 16 address bits are chopped by the PPC! Good to know but in my linker script the interrupt vector starts at 0x00000000 >=20 > (2) Downloading a bitfile via Impact, there was one (probably V2Pro-speci= fic) > tick box that had to be set to reset the PPC correctly. The only reason I > mention this was that starting via XMD worked correctly. Yes, there was this box for V2P FPGAs. >=20 > - Brian >=20 Thank you all for your help. I solved the problem with the help of the second PowerPC core integrated in the Virtex 5. MartinArticle: 147529
On Apr 26, 11:14=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > Similar problem, yes. =A0It is possible to specify an invalid IOTYPE > when instantiating an IOBUF. =A0Not a single step in the chain detects > it - it goes all the way -through- bitgen without a single warning. > At least it sounds like this issue is consistent. What I encountered is more like voodoo.Article: 147530
On 29/04/2010 19:16, Wastrel wrote: > On Apr 28, 1:40 am, David Brown<da...@westcontrol.removethisbit.com> >> I know you've already found the answer, but this is just for >> completeness sake... >> >> There are some suppliers that still produce systems with XP installed - >> Dell being perhaps the best known. They refer to it as "Win 7 Pro >> downgraded to XP", and charge extra for it. I think of it as "Win 7 >> /upgraded/ to XP", and think it is worth the money. There are many >> tools in the embedded development world that don't play well with >> anything other than XP. Win 7 64-bit works better than XP 64-bit, so if >> you need more than 3.5 GB memory, Win 7 is a good choice. But other >> than that I have seen no reason to pick Win 7 over XP, and XP is always >> faster on the same hardware. >> >> As has been suggested, an alternative is to use virtual machines. I >> recommend Virtual Box - it's perhaps not quite as integrated as the "XP >> mode" of Win 7 Pro, but it is much more flexible. It's also free and >> cross-platform, and you can move the virtual machines between different >> hosts.- Hide quoted text - >> >> - Show quoted text - > > I'll have to look into some of these virtual machines. I'm sure this > won't be the only speedbump I hit doing embedded development under > Win7. What kind of performance hit can I expect? In the old days I > used to fool around with CPM 2.2/Z80 emulators under DOS and WINE > under Linux and my impression then was " well isn't that cute", but > never considered really working in that environment. I imagine they > have come a ways since then. > > Bob If you are going to try virtual machines, I'd wait just a little bit longer until Virtual Box 3.20 is out - it's in beta testing at the moment. It has some nice new features such as better multiple monitor support, faster guest booting and host-initiated execution of guest programs. Performance under VirtualBox is very good for most purposes - I use it extensively for things like embedded Linux build systems that do a great deal of compilation. Some software, such as graphics-intensive software, is going to be slower - 3-D acceleration exists but is not perfect and has limitations (don't expect to use the guest for running modern 3D games). But for most purposes the overhead is no more than a few percent. For old DOS software, the most powerful emulator is DOSBOX. It doesn't really matter if it has some overhead - a modern PC is still much faster than a DOS-era machine. WINE gives variable results depending on the system, the version of WINE, and the program you want to run. For some software it works very well, others not at all. If the software in question is a stand-alone program it is typically fine, but if it interacts with many other programs, or hardware drivers, it will have trouble. DirectX acceleration works to some extent. But if the software runs okay, it is may be faster than running natively on Windows - several of the key WINE libraries are faster than the native Windows versions, and the WINE programs take advantage of Linux's faster file system. Graphics, on the other hand, will often be slower due to extra translation layers. Number crunching will be the same - it runs natively on the processor.Article: 147531
On 30 Apr, 10:04, Eli <eli.billa...@gmail.com> wrote: > On Apr 26, 11:14=A0pm, d_s_klein <d_s_kl...@yahoo.com> wrote: > > > Similar problem, yes. =A0It is possible to specify an invalid IOTYPE > > when instantiating an IOBUF. =A0Not a single step in the chain detects > > it - it goes all the way -through- bitgen without a single warning. > > At least it sounds like this issue is consistent. What I encountered > is more like voodoo. I've just discovered that "DCI CASCADE" can be applied in the wrong order for a VIRTEX5 I'm working with. The whole problem is that XILINX does its regression testing on its software using DESIGNS THAT ARE CORRECT. Whereas the vast majority of compilations that users do are on designs that are wrong. Colin .Article: 147532
On 4/29/2010 5:09 PM, Ehsan wrote: > Hi fellows, > > I have been working on a Virtex5 LX110 design using VHDL and ISE > tools. My problem is that I cannot meet my timing constraints or the > desired clock frequency. When I look at the timing report, I realized > that the large delay is due to a signal with a large fanout. Dear Ehsan, When the tools find a net which it cannot route and meet the timing it gives up trying to meet the timing on all the other nets as well. Unless your 'large fanout' net is the only net which is failing timing, the problem may well lie with another net. HTH., Syms.Article: 147533
pes <dontspamme@thanks.com> wrote: >Hi, > >I' m new to FPGA and I want to design a board with a Xilinx Spartan6 >FPGA and 4GB of RAM. >Is it realistic to have a such quantity of RAM on a board? I suppose >that there are design constraints to do it, is it easier to do it with >DDR2 than DDR3 or others? >The Spartan6 integrated memory controller only treats 16bits bus, I >suppose I can' t use easily DIMM memory? I think you can if your design goals are realistic. A 125MHz DDR2 interface (250Mbit/s) should be feasible but you should be willing to roll your own DDR2 controller. A couple of years ago I created a design in which a standard PC style DDR dimm module is shared between two Spartan3 (speed grade 4) FPGAs. One FPGA contains the DDR controller the other is just a slave. BTW I've started to convert this design to DDR2. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 147534
I have a design in a Virtex 5 with an asynchronous fifo that has a write clock of 100 MHz and a read clock of 300 MHz. Both clocks are driven from a PLL. I want to tell Synplify that the two clocks can be in different clock groups for timing and so have a false path between them. However Synplify just looks at the input clock on the PLL and then auto defines the other two clocks and puts them in the same clock group. Any ideas how I seperate them into two groups? Thanks Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147535
I have used two home-grown functions for years for this: is1() and is0(). Both handle metavalues, etc. if is1(A and B) then No silly syntax or language "improvements" required. AndyArticle: 147536
On Apr 30, 2:28=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > On 29/04/2010 19:16, Wastrel wrote: > > > > > > > On Apr 28, 1:40 am, David Brown<da...@westcontrol.removethisbit.com> > >> I know you've already found the answer, but this is just for > >> completeness sake... > > >> There are some suppliers that still produce systems with XP installed = - > >> Dell being perhaps the best known. =A0They refer to it as "Win 7 Pro > >> downgraded to XP", and charge extra for it. =A0I think of it as "Win 7 > >> /upgraded/ to XP", and think it is worth the money. =A0There are many > >> tools in the embedded development world that don't play well with > >> anything other than XP. =A0Win 7 64-bit works better than XP 64-bit, s= o if > >> you need more than 3.5 GB memory, Win 7 is a good choice. =A0But other > >> than that I have seen no reason to pick Win 7 over XP, and XP is alway= s > >> faster on the same hardware. > > >> As has been suggested, an alternative is to use virtual machines. =A0I > >> recommend Virtual Box - it's perhaps not quite as integrated as the "X= P > >> mode" of Win 7 Pro, but it is much more flexible. =A0It's also free an= d > >> cross-platform, and you can move the virtual machines between differen= t > >> hosts.- Hide quoted text - > > >> - Show quoted text - > > > I'll have to look into some of these virtual machines. I'm sure this > > won't be the only speedbump I hit doing embedded development under > > Win7. What kind of performance hit can I expect? In the old days I > > used to fool around with CPM 2.2/Z80 emulators under DOS and WINE > > under Linux and my impression then was " well isn't that cute", but > > never considered really working in that environment. I imagine they > > have come a ways since then. > > > Bob > > If you are going to try virtual machines, I'd wait just a little bit > longer until Virtual Box 3.20 is out - it's in beta testing at the > moment. =A0It has some nice new features such as better multiple monitor > support, faster guest booting and host-initiated execution of guest > programs. > > Performance under VirtualBox is very good for most purposes - I use it > extensively for things like embedded Linux build systems that do a great > deal of compilation. =A0Some software, such as graphics-intensive > software, is going to be slower - 3-D acceleration exists but is not > perfect and has limitations (don't expect to use the guest for running > modern 3D games). =A0But for most purposes the overhead is no more than a > few percent. > > For old DOS software, the most powerful emulator is DOSBOX. =A0It doesn't > really matter if it has some overhead - a modern PC is still much faster > than a DOS-era machine. > > WINE gives variable results depending on the system, the version of > WINE, and the program you want to run. =A0For some software it works very > well, others not at all. =A0If the software in question is a stand-alone > program it is typically fine, but if it interacts with many other > programs, or hardware drivers, it will have trouble. =A0DirectX > acceleration works to some extent. =A0But if the software runs okay, it i= s > may be faster than running natively on Windows - several of the key WINE > libraries are faster than the native Windows versions, and the WINE > programs take advantage of Linux's faster file system. =A0Graphics, on th= e > other hand, will often be slower due to extra translation layers. > Number crunching will be the same - it runs natively on the processor.- H= ide quoted text - > > - Show quoted text - Interesting David. Thanks for the info. BobArticle: 147537
On Apr 29, 5:15=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 29 Apr 2010 05:42:47 -0700 (PDT), rickman <gnu...@gmail.com> wrot=
e:
> >On Apr 29, 7:12=A0am, Brian Drummond <brian_drumm...@btconnect.com>
> >wrote:
> >> On Wed, 28 Apr 2010 16:55:13 -0700 (PDT), rickman <gnu...@gmail.com> w=
rote:
> >> >That is one long reply...
>
> >> I'm unclear why you say a separate concurrent statement facilitates de=
bugging;
> >> are you stepping through code in the simulator? (I haven't done that i=
n over ten
> >> years)
>
> >Not for stepping, although I sometimes do that. =A0It is so I can put up
> >each result in the simulator...
>
> >DCO <=3D DCO + (Integrated / INTG_GAIN) + (ErrorReg * PROP_GAIN);
>
> >This is overflowing an intermediate result. =A0How do you debug?
>
> Sometimes, not very well...
>
> But for this situation I would assert properties of the expression, or be=
tter,
> of each intermediate term.
>
> So for example, (ErrorReg * PROP_GAIN) might have its own intermediate si=
gnal -
> (in my code it almost certainly would - within the main process - so I ca=
n
> control its pipelining but that's another story * ) - I could assert the =
output
> sign matches the input sign (knowing, or asserting, PROP_GAIN is positive=
).
Pipelining is not possible. This is a PLL and adding register delays
changes the nature of the equation. Yes, you can assert things in
simulation, but what do you do in the chip? I had to debug a problem
in the board when the simulation worked perfectly. In fact, I am very
happy with the PLL, it locks in fast and holds the lock tightly. The
problem ended up being a configuration (real time, not compile)
mistake. But it took some real debugging of the PLL to figure that
out.
> (* I've had summer interns exploring register retiming tools; =A0they did=
n't beat
> my hand-timed results. Which may say something about the tools, or not)
>
> Then either I get a pinpoint report of the problem, or the testbench is
> inadequate...
Actually, yes, in this case a 100% test bench would have caught the
real problem. I wasn't simulating the configuration module which
received the serial config commands. This has bitten me twice, but it
is one of those things where the customer was beating on me to get
something to him to test and I didn't have time to get the last
touches into the top level test bench. Sometimes working the "right"
way appears to be "slow". In this case it cost us about a week of lab
test time vs. about a week of additional test bench design and use. I
am working on the 100% simulation now mainly because I still have to
build a test fixture, the hardware kind, and that uses an FPGA which
the test bench will be programming. The other bug was actually a bug
in the config code which didn't disable multiple use of the same
register bits between two modes. A squelch circuit was activated in a
mode where there wasn't supposed to be any squelch.
> >> A better solution all round would be to replace it with an if-expressi=
on (in
> >> which "if", "then", "else" are explicit, (don't rely on the reader kno=
wing C)
> >> and a case-expression for the (n>2) enumeration and integer subrange c=
ases.
>
> >> But that seems to have fallen out of favour since Algol-W.
>
> >I'm not sure what you are referring to. =A0An if is a sequential control
> >flow structure. =A0
>
> Maybe in some languages, but it doesn't have to be.
>
> I used to be able to write code of the form
> ----
> =A0 =A0a :=3D if <expr1> then <expr2> [ else <expr3>];
> ----
> (the assignment being skipped if expr1 was false and there was no else cl=
ause)
> and similarly, case expressions with semantics like case statements.
>
> And I am delighted to hear it's on the way back in a mainstream language =
and one
> of the main influences on VHDL.
>
> >foo <=3D ralph + (('1' =3D Mode) ? A : B);
>
> >compared to
>
> >with Mode select
> > =A0foo <=3D ralph + A when '1',
> > =A0 =A0 =A0 =A0 ralph + B when '0',
> > =A0 =A0 =A0 =A0 (others =3D> '-') when others;
>
> I think a closer translation would be
>
> foo <=3D ralph + A when Mode =3D '1' else ralph + B;
>
> and I don't get the objection to that.
Yeah, but in simulation I always use the others to catch "illegal"
states in controls. In your code a value of 'u' in Mode results in
foo <=3D ralph + B and the circuit continues with no problem. I want to
propagate crap with crap. Typically operators do that with std_logic
while your simpler logic doesn't.
In fact, it is only a warning when you have two drivers of an
std_logic signal. I would like to make that an error by using
std_ulogic, but I'm not sure how that works with the other types. I
need to investigate that sometime.
> I doubt there's a synthesis tool alive that would duplicate the adder!
> But if there were, I would mux A or B onto =A0an intermediate signal .
>
> >I don't get the "break" part. =A0I think that is a subjective opinion.
> >> >I don't get why you think the conditional operator would be a wart.
> >> >It is just an operator. =A0It is a trinary operator rather than uniar=
y
> >> >or binary,
> >> For a start, what would the syntax for overloading it look like?
>
> >Why would it be any different from what we currently use??? =A0What does
> >it look like?
>
> What we currently use and overload are unary and binary operators. In nei=
ther of
> these do you have to split the operator symbol in half and insert an argu=
ment in
> the middle.
>
> There is no syntax for expressing that, in VHDL.
>
> That is what I mean by "break". I suspect we'd have to try writing the BN=
F for a
> grammar that would handle its use and overloading to settle the question.
If it is a part of VHDL 2008, isn't it done? I can't imagine they
would have added it to the standard if vendors didn't know how to make
it work yet.
> >> And definitely not worth rewriting half the parser for one operator on=
one
> >> specific enumerated type.
>
> >Ok, now you are going off to unsubstantiated claims. =A0I doubt anyone
> >would agree to go with a feature that required rewriting half the
> >compiler.
>
> Maybe so, my compiler writing days are long ago. But something about addi=
ng
> *one* trinary operator sets off alarm bells.
I guess we can ask the vendors about it. Does anyone have VHDL in
their tools yet? Mine don't seem to include it, but that may be a
switch I need to throw.
Rick
Article: 147538On Apr 30, 4:06=A0pm, rickman <gnu...@gmail.com> wrote: > Yeah, but in simulation I always use the others to catch "illegal" > states in controls. =A0In your code a value of 'u' in Mode results in > foo <=3D ralph + B and the circuit continues with no problem. =A0I want t= o > propagate crap with crap. =A0Typically operators do that with std_logic > while your simpler logic doesn't. I replied earlier about using trivial, home-grown is1() and is0() functions that will let you know about metavalues with an assertion warning (default, can be altered with optional arg), as well as appropriately handle a weak logic value. This is the main reason I wrote them and have used them for years. If you set severity appropriately, the debugger will stop exactly where the meta-value was detected, rather than waiting until you notice garbage data, and trace it back to its cause. foo <=3D ralph + A when is1(Mode) else ralph + B; I'm beginning to wonder how pleased you will be with verilog, given some of the features of vhdl you already use. AndyArticle: 147539
On Fri, 30 Apr 2010 14:06:19 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:
>On Apr 29, 5:15 pm, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> >Not for stepping, although I sometimes do that. It is so I can put up
>> >each result in the simulator...
>>
>> >DCO <= DCO + (Integrated / INTG_GAIN) + (ErrorReg * PROP_GAIN);
>>
>> >This is overflowing an intermediate result. How do you debug?
>> for example, (ErrorReg * PROP_GAIN) might have its own intermediate signal -
>> (in my code it almost certainly would - within the main process - so I can
>> control its pipelining but that's another story * ) - I could assert the output
>> sign matches the input sign (knowing, or asserting, PROP_GAIN is positive).
>
>Pipelining is not possible. This is a PLL and adding register delays
>changes the nature of the equation. Yes, you can assert things in
>simulation, but what do you do in the chip?
I understand about pipelining in your case; you're right it wouldn't
work (introducing additional poles).But you can still use intermediate
(combinatorial) signals.
And yes you can run many more cycles on the chip - as well as find
unforeseen circumstances - that you can't in sim.
In places (which means I am inconsistent about it ) I have adopted
"hardware asserts" using sticky bits, of the form
process(clk)
begin
if rising_edge(clk) then
shouldnt_happen <= (the expression you would assert);
if clear then
shouldnt_happen_stky <= '0';
else
shouldnt_happen_stky <= shouldnt_happen_stky or
shouldnt_happen;
end if;
end if;
end process;
I collect all the sticky bits into a health monitor register which I
read (and then clear) at leisure. Hardware cost is completely trivial
unless you're using a CPLD.
If any of them trigger, they show which part of the design to focus on,
and make ideal trigger signals for Chipscope.
> I had to debug a problem
>in the board when the simulation worked perfectly. In fact, I am very
>happy with the PLL, it locks in fast and holds the lock tightly. The
>problem ended up being a configuration (real time, not compile)
>mistake. But it took some real debugging of the PLL to figure that
>out.
Good work. (nice story of real world snipped...)
>> >foo <= ralph + (('1' = Mode) ? A : B);
>>
>> >compared to
>>
>> >with Mode select
>> > foo <= ralph + A when '1',
>> > ralph + B when '0',
>> > (others => '-') when others;
>>
>> I think a closer translation would be
>>
>> foo <= ralph + A when Mode = '1' else ralph + B;
>>
>> and I don't get the objection to that.
>
>Yeah, but in simulation I always use the others to catch "illegal"
>states in controls. In your code a value of 'u' in Mode results in
>foo <= ralph + B and the circuit continues with no problem.
Agreed, but my point was ... the ?: operator does that too!
I didn't say it was a better translation, just more accurate.
> I want to
>propagate crap with crap. Typically operators do that with std_logic
>while your simpler logic doesn't.
So this is a case where the additional verbosity comes, not from the
language missing a useful operator, but from your wish (which I agree
with) to do a better job.
>In fact, it is only a warning when you have two drivers of an
>std_logic signal. I would like to make that an error by using
>std_ulogic, but I'm not sure how that works with the other types. I
>need to investigate that sometime.
That's an example of people (myself included) not having pushed the
language capabilities far enough in raising quality or productivity. We
just use std_logic because the tools (templates, Xilinx examples, etc)
just assume it's the default we want to use. But really, outside of
3-state buses, std_ulogic[_vector] should be the default.
I suspect there may be some tools issues in the less-well-trodden path
of std_ulogic. And I have a nagging suspicion that numeric_std is
compatible with std_logic and may be harder to use with its unresolved
cousin. (But I hope not)
Again, if you get a chance to investigate, I would be interested to hear
how you get on.
>> That is what I mean by "break". I suspect we'd have to try writing the BNF for a
>> grammar that would handle its use and overloading to settle the question.
>
>If it is a part of VHDL 2008, isn't it done? I can't imagine they
>would have added it to the standard if vendors didn't know how to make
>it work yet.
?: in the C (Verilog?) form is not in VHDL2008, as far as I know. But
there are other (more VHDL-friendly) improvements in the same area.
>> >Ok, now you are going off to unsubstantiated claims. I doubt anyone
>> >would agree to go with a feature that required rewriting half the
>> >compiler.
>>
>> Maybe so, my compiler writing days are long ago. But something about adding
>> *one* trinary operator sets off alarm bells.
>
>I guess we can ask the vendors about it. Does anyone have VHDL in
>their tools yet? Mine don't seem to include it, but that may be a
>switch I need to throw.
Some support bits of VHDL2008, but support is still pretty poor.
- Brian.
Article: 147540On Apr 30, 11:16=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > I have a design in a Virtex 5 with an asynchronous fifo that has a write > clock of 100 MHz and a read clock of 300 MHz. Both clocks are driven from= a > PLL. I want to tell Synplify that the two clocks can be in different cloc= k > groups for timing and so have a false path between them. However Synplify > just looks at the input clock on the PLL and then auto defines the other > two clocks and puts them in the same clock group. Any ideas how I seperat= e > them into two groups? > > Thanks > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > Posted throughhttp://www.FPGARelated.com You can add constraints on the output of PLL and put them in different clock groups. This would automatically create a false path between the clocks. -- AmalArticle: 147541
On Apr 29, 5:42=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 28 Apr 2010 12:33:21 +0100, Alan Fitch <alan.fi...@spamtrap.com> = wrote: > How many times have you wanted to write something like this: > if A and B then > where A and B are STD_LOGIC? ... You have to write this instead: > if A =3D '1' and B =3D '1' then > You don't HAVE to write it that way...it can also be written (just as clearly in my opinion, but a few more taps on the keyboard then VHDL-2008) if (A and B) =3D '1' then KJArticle: 147542
On Apr 30, 6:56=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Fri, 30 Apr 2010 14:06:19 -0700 (PDT), rickman <gnu...@gmail.com> > >In fact, it is only a warning when you have two drivers of an > >std_logic signal. =A0I would like to make that an error by using > >std_ulogic, but I'm not sure how that works with the other types. =A0I > >need to investigate that sometime. > <snip> > I suspect there may be some tools issues in the less-well-trodden path > of std_ulogic. And I have a nagging suspicion that numeric_std is > compatible with std_logic and may be harder to use with its unresolved > cousin. (But I hope not) > > Again, if you get a chance to investigate, I would be interested to hear > how you get on. > I've been using std_ulogic/std_ulogic_vector for a while...no issues with Quartus or Synplify on the synthesis front. The only downside is some extra type conversions to convert between the vectors where you have to for some reason have std_logic_vector. The upside of course is that the compiler immediately flags when you have multiple drivers on a net, you don't have to sim/debug to find that out. The main place the mixing of std_logic_vector and std_ulogic_vector occurs is instantiating some outside widget that uses std_logic_vector on the interface. Once I learned that type conversions can be put into the port map and you didn't need to create std_ulogic 'wrappers', or use intermediate signals to connect the vectors, it all came together rather nicely. Example: Inst_Some_Widget : entity work.widget port map( Gazinta_slv =3D> std_logic_vector(Gazinta_sulv), std_logic_vector(Gazouta_slv) =3D> Gazouta_sulv ); std_logic and std_ulogic can be freely assigned without any type conversions Kevin JenningsArticle: 147543
On Apr 26, 3:59=A0pm, Eli <eli.billa...@gmail.com> wrote:
> Hello,
>
> I'm running ISE 9.2.03i on a design for Spartan 3E (3s250e-4tq144).
>
> For whoever wishes to skip the long description below, the idea is
> simple: The tools should not agree to place pins with conflicting IO
> standards, such as LVTTL and LVCMOS25, on the same bank. And suddenly
> I caught the tools not noticing this. This clearly looks like a bug,
> among others because slight tweaks with the source Verilog makes the
> tools reject the conflict, as they should.
>
> My question is if someone has had similar experience, and if there's a
> way to be sure that the tools indeed detect collisions when they
> occur.
>
> And now to the long story, for those who want the details. A lot of
> details, which I doubt if they're relevant. But anyhow.
>
> Recently, I've been doing this pin placement back-and-forth with the
> board designer. Since the logic isn't written yet, I've written dummy
> logic for the I/O pins. So each time the board designer wants a
> change, I make the change in the UCF file, run an implementation, and
> see if there are complaints. If they do, I get an error like the
> example at the bottom of this post (in case of an IO standard
> violation), or errors about problems in clock routing. For a few
> years, this has been my method to quickly approve pinouts, until this
> method failed recently.
>
> What I found out, is that the tools agreed to place LVTTL pins and
> LVCMOS25 on the same bank, if they were defined as inouts (that is,
> bidirectional). I verified this by looking at the pad report and with
> FPGA editor. If I made both pins outputs, the tools refused, as they
> should. Other irrelevant tweaks with the code (such as commenting out
> irrelevant parts) also woke up the sleeping guard.
>
> The method I use for checking is instantiating a module like at the
> bottom of this message. The IOSTANDARD parameter is set at
> instantiation to the desired standard. The module generates DDR flip-
> flops for both input and output, so if placement and routing succeeds,
> I know that the certain pin's placement is OK, and that IOB registers
> with the given clock can be packed. Or so I thought.
>
> I have, of course, other modules for input-only, output-only,
> nonclocked IOs, differential IOs and such.
>
> This looks like a bug in the tools. Unfortunately, I failed to make a
> simple example which demonstrates the bug. It looks like the tools are
> OK most of the time, but it's disturbing that they may fail on me even
> once (and make me approve a faulty board design).
>
> So has anyone encountered a similar problem?
>
> Thanks in advance,
> =A0 =A0 Eli
>
> ---------------------------
>
> Example of error from placer.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
>
> ERROR:Place:864 - Incompatible IOB's are locked to the same bank 3
> =A0 =A0Conflicting IO Standards are:
> =A0 =A0IO Standard 1: Name =3D LVCMOS25, VREF =3D NR, VCCO =3D 2.50, TERM=
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 data<0>
> =A0 =A0 =A0 =A0 data<1>
>
> =A0 =A0IO Standard 2: Name =3D LVTTL, VREF =3D NR, VCCO =3D 3.30, TERM =
=3D NONE
> =A0 =A0List of locked IOB's:
> =A0 =A0 =A0 =A0 testpoints<1>
> =A0 =A0 =A0 =A0 testpoints<3>
>
> The test module
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> module testiob #(parameter IOSTANDARD =3D "LVTTL")
> =A0 =A0(inout pin,
> =A0 =A0 input clk);
>
> =A0 =A0wire =A0 in, out, T;
> =A0 =A0wire =A0 in_fall, in_rise;
>
> =A0 =A0reg =A0 =A0in_fall_d, in_rise_d;
>
> =A0 =A0always @(posedge clk)
> =A0 =A0 =A0begin
> =A0 =A0 =A0 =A0 in_fall_d <=3D in_fall;
> =A0 =A0 =A0 =A0 in_rise_d <=3D in_rise;
> =A0 =A0 =A0end
>
> =A0 =A0// This is completely useless setting. It just puts the IOB in
> place.
> =A0 =A0// It may drive the lines crazy if used for real
>
> =A0 =A0IOBUF =A0#(.IOSTANDARD(IOSTANDARD)) iobuf
> =A0 =A0 =A0(.IO(pin), .I(out), .O(in), .T(T));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) out_ddr
> =A0 =A0 =A0(.Q (out),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0ODDR2 #(.SRTYPE("ASYNC")) T_ddr
> =A0 =A0 =A0(.Q (T),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE (1'b1),
> =A0 =A0 =A0 .R (1'b0),
> =A0 =A0 =A0 .D0 (in_rise_d),
> =A0 =A0 =A0 .D1 (in_fall_d),
> =A0 =A0 =A0 .S (1'b0));
>
> =A0 =A0IDDR2 #(.SRTYPE("ASYNC")) in_ddr
> =A0 =A0 =A0(
> =A0 =A0 =A0 .Q0 =A0 (in_rise),
> =A0 =A0 =A0 .Q1 =A0 (in_fall),
> =A0 =A0 =A0 .C0 =A0 (clk),
> =A0 =A0 =A0 .C1 =A0 (!clk),
> =A0 =A0 =A0 .CE =A0 (1'b1),
> =A0 =A0 =A0 .D =A0 =A0(in),
> =A0 =A0 =A0 .R =A0 =A0(1'b0),
> =A0 =A0 =A0 .S (1'b0));
>
> endmodule
Xilinx pin configuration has been brain-dead forever. It is slightly
better now, but not enough that it could be classified as "good."
I haven't manually generated UCF files in over a decade. Back then,
the Xilinx tools would do *exactly* the wrong thing (from my
perspective): if your top-level design had a net that wasn't in the
UCF, the tools would blithely assign the net to some random pin on the
package (bad), and if your UCF had a pin that wasn't in your top-level
design (perhaps because you were defensively coding your UCF in
advance of your design because of the other issue), the tools would
abort and complain about not having the pin in the design.
The tools are a bit better now, giving you some options on these
things, but I still don't trust them.
ALSO, with the different I/O standards, you have to realize that you
are inviting issues if you don't carefully control the UCF to match
the board design.
The only right answer is a script that reads in the top level HDL, the
schematic netlist, and the Xilinx package file, and spits out a UCF
file. (Because I'm paranoid, I put "PROHIBIT" on all pins on the part
that aren't in the netlist; then if the design is built with changes
without rerunning the UCF script, it will barf.)
Regards,
Pat
Article: 147544>You can add constraints on the output of PLL and put them in different >clock groups. This would automatically create a false path between >the clocks. > >-- Amal I could declare each clock and put it in a different group but Synplify just ignores them as it finds the clocks by looking at the PLL and sets them in the same clock group. I need some way to overide this and create two different clock groups. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 147545
Hi I wanna give some student a tutorial about FPGA programming and I wonder if there are any cheap FPGA evaluation kits out there that I could get? Needs to be nothing special, just a small board with some LEDS would be fun. THanks for any useful links, AndrewArticle: 147546
Andrew Pichler wrote: > I wanna give some student a tutorial about FPGA programming and > I wonder if there are any cheap FPGA evaluation kits out there > that I could get? Needs to be nothing special, just a small board > with some LEDS would be fun. You can get some nice and cheap modules here: http://www.trenz-electronic.de/products/fpga-boards/oho-elektronik.html Or maybe this one, if you prefer Altera: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=39&No=215 A list with more boards: http://www.fpga-faq.com/FPGA_Boards.shtml Maybe you should ask the companies for discount for students and if you need more than one board. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 147547
On Fri, 30 Apr 2010 17:52:10 -0700 (PDT), KJ <kkjennings@sbcglobal.net> wrote: >On Apr 30, 6:56 pm, Brian Drummond <brian_drumm...@btconnect.com> >wrote: ><snip> >> I suspect there may be some tools issues in the less-well-trodden path >> of std_ulogic. And I have a nagging suspicion that numeric_std is >> compatible with std_logic and may be harder to use with its unresolved >> cousin. (But I hope not) > >I've been using std_ulogic/std_ulogic_vector for a while...no issues >with Quartus or Synplify on the synthesis front. Good to know. Seen any extra cruft getting to/from numeric_std? >Once I learned that type conversions can be put >into the port map and you didn't need to create std_ulogic 'wrappers', >or use intermediate signals to connect the vectors, it all came >together rather nicely. > >Example: > >Inst_Some_Widget : entity work.widget >port map( > Gazinta_slv => std_logic_vector(Gazinta_sulv), > std_logic_vector(Gazouta_slv) => Gazouta_sulv >); Port map conversions (not this one) are one area where I have seen (and reported) problems with Xilinx ISIM. Not show-stoppers, I just have to put the conversions elsewhere and wait patiently for Xilinx to fix it. But it's my experience that tools issues are a big cause of "drag" in learning to improve my use of VHDL. - BrianArticle: 147548
On Sat, 01 May 2010 09:42:11 +0100, Andrew Pichler <Andrew@yahoo.com> wrote: >Hi > >I wanna give some student a tutorial about FPGA programming and >I wonder if there are any cheap FPGA evaluation kits out there >that I could get? Needs to be nothing special, just a small board >with some LEDS would be fun. > >THanks for any useful links, These ones look tailor-made for the job! http://www.enterpoint.co.uk/polmaddie/polmaddie_family.html My preference would be for the Spartan-3 version, or possibly the Altera if the chip has similar capacity. Both have well-developed free toolchains. - BrianArticle: 147549
On May 1, 6:35=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Fri, 30 Apr 2010 17:52:10 -0700 (PDT), KJ <kkjenni...@sbcglobal.net> > >I've been using std_ulogic/std_ulogic_vector for a while...no issues > >with Quartus or Synplify on the synthesis front. > > Good to know. Seen any extra cruft getting to/from numeric_std? > No. KJ
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