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
Whilst I agree with the principle, Mike. It was perhaps a tad harsh sounding. Ben (aka VHDL) Cohen hasn't struck me as a shameless self promotor on here. Anyway I look forward to the book when it arrives here in England. Its a bit of a shame its not featured at any of the major booksellers online and only at www.vhdlcohen.com AFAIK Paul Baxter (also with a munged email address registered, but its pauljnospambaxter@hotnospammail.com without the nospams) "Mike Treseler" <tres@tc.fluke.com> wrote in message news:3C93BE9C.87F44C40@tc.fluke.com... > strut911 wrote: > > > i just wanted to give everyone a heads up on my experience with this > > book. if you want to learn more about chip/fpga design and > > verification, at least the way it is done by professionals, i > > recommend this book. > > I would find this review much more credible > if Mr. Strut911 from hotmail.com > would identify himself. > > -- Mike TreselerArticle: 40851
> > i just wanted to give everyone a heads up on my experience with this > > book. if you want to learn more about chip/fpga design and > > verification, at least the way it is done by professionals, i > > recommend this book. > > I would find this review much more credible > if Mr. Strut911 from hotmail.com > would identify himself. > > -- Mike Treseler Same thought came to my mind....though he's posted in comp.arch.fpga before... Out of curiosity, and not meaning to sound crass (me, no) but don't they teach the use of capital letters, two spaces after a period, and a line break between paragraphs in school these days? AustinArticle: 40852
"Austin Franklin" <austin@dar55kroom.com> wrote in message news:u97jr0cosbpc33@corp.supernews.com... > Out of curiosity, and not meaning to sound crass (me, no) but don't they > teach the use of capital letters, two spaces after a period, and a line > break between paragraphs in school these days? > > Austin > I certainly hope they don't teach two spaces after a period. That's a typographical no-no that went out with the typewriter. ObFPGA. Anybody got sensible speed numbers from Leonardo/Stratix yet?Article: 40853
You can use it too, it just isn't documented. The block can be wired from within the FPGA editor. It is a strictly combinatorial block, intended to get the OE turned around from trdy/irdy quickly. I'm not sure if the current software will recognize the block if you put it in the edif netlist (direct instantiation of a black box in your source), there was mention that perhaps it did a while back here...I haven't tried it. If it does, you are nearly home free, if not, then you can always add it as a hard macro generated in FPGA editor. Dan wrote: > Thanks for the input. > > Which signals can not be registered ? > > Do you mean TRDY and IRDY ? > > Xilinx told me that the dedicated IRDY & TRDY pins do have different logic > than the other IO pins. But they said that they do not publish the > difference and that only Xilinx can use it. > > Sincerely > Daniel DeConinckArticle: 40854
Pete Fraser wrote > > "Austin Franklin" <austin@dar55kroom.com> wrote in message > news:u97jr0cosbpc33@corp.supernews.com... > > > Out of curiosity, and not meaning to sound crass (me, no) but don't they > > teach the use of capital letters, two spaces after a period, and a line > > break between paragraphs in school these days? > > > > Austin > > > I certainly hope they don't teach two spaces after a period. > That's a typographical no-no that went out with the typewriter. You try getting your fingers to forget it...Article: 40855
Dan wrote:
>
> Hi Kevin,
>
> First off, thanks for lots of great input.
>
> So which ones can not be registered ?
>
When transitioning from an idle state to an address decode state
(PCI specification Appendix B target state machine doesn't have such a
state, but I added such a state in my design), the PCI IP core has to
monitor FRAME# and IRDY#, and when FRAME# = 'L' and IRDY# = 'H', it
should transition to an address decode state.
In Appendix B, the example transitions to a bus busy state, but I didn't
like that, so I did it differently.
However, it is pretty much a requirement to implement a bus busy state,
and I will explain that later.
Regardless, using a registered version of whatever signal means
incurring one cycle of delay, and when determining when the target state
machine should get out of an idle state, and transition to an address
decode state, that one cycle of delay will mess things up.
Unfortunately, a lot of things in PCI in my opinion cannot be
registered, and especially so regarding control signals (FRAME#, IRDY#,
DEVSEL#, TRDY#, STOP#, and PAR).
> >I finally figured out a way to activate that mysterious PCILOGIC thing
> >I can E-mail the sample code to anyone interested.
> I accept your offer support@pixelsmart.com
>
> Tsu < 7ns. I assumed that this applied to PCI input signals. I use a
> dedicated clock input and the high speed clock routing. All input FFs are in
> the IOB and get latched at the same time. I thought that was all that could
> be done and all that should be done to input PCI signals.
Some unregistered control signals have to go through multiple
levels of LUT, and reach another IOB output FF or OE FF (tri-state
control FF).
For example, in target mode, unregistered FRAME# and IRDY# will
influence the outcome of DEVSEL#, TRDY#, and STOP#'s output FF and OE
FF, and for timing reasons, those FFs have to be within IOBs.
So, latching unregistered FRAME# and IRDY# within an IOB input FF or
regular CLB FF, and influencing the outputs of DEVSEL#, TRDY#, and STOP#
will be too late in some cases like when the PCI IP core detected an end
to a burst transfer, or when waiting for FRAME# to get deasserted in a
backoff state (STOP# and DEVSEL# have to be immediately deasserted when
FRAME# is deasserted.).
> I get the feeling
> that I am missing the point on Tsu. What am I missing ?
> Tsu: where is this measured from and to ?
>
For 33MHz PCI, Tsu has to be < 7ns, and it is defined as 7ns
before a positive edge of a clock strikes.
However, in practice, you have about 2.5ns more global clock delay
within a Spartan-II XC2S150-5CPQ208 (the chip Insight Electronics PCI
card uses), but that global clock delay can be significantly less in
some other FPGAs (device dependent).
Using Floorplanner is the most effective way of reducing Tsu in addition
to reducing levels of LUT through simplifying the design.
> >I heard some chipsets don't let PCI devices that don't implement
> configuration registers function at all by cutting off clock supply to it.
>
> I heard the same thing about the PCI clock being disabled.
>
> >What are the chipsets do the motherboards you got have?
> I have not even looked at my mother board chipset.
>
In theory, ANY PCI card should work with ANY motherboard that
has PCI slots, but in practice, some designers seem test it only on
Intel chipsets, and not on other chipsets (VIA, SiS, ALi, AMD, etc.).
VIA or SiS has a lot more market share than 4 or 5 years ago (Intel
seemed to had 90% market share in motherboard chipsets at one point.),
so assuming that people will only have an Intel chipset in their
computers is probably not a safe idea.
Otherwise, you will get buggy cards that work on certain computer, but
not on others, and certainly customers who know almost nothing about PCI
will pay for that.
> >You should never assume that burst read cycle won't occur.
> I have always heard people complaining that wintel platforms do not busrt
> read. Is this just a myth ? Do some of them acctually burst read ?
>
Yes, I think it is true that x86 processors don't do read
bursts, and my theory is that most memory read instructions cannot be
posted unlike memory write instructions.
I don't own a logic analyzer, and don't have access to it, so I haven't
actually seen it.
However, Intel and AMD recently added prefetch instructions in their
latest processors, so who knows, someone may write some code trying to
prefetch data from your PCI card's memory map.
Besides that, as far as I know, NO where in the PCI specification says
"In x86 platforms, a host bridge doesn't initiate burst read cycles," so
you have to design your PCI IP core knowing that it might happen.
At least, that's how I did mine.
Plus, in PCI, any bus master device can initiate burst read cycles, and
you cannot tell if that device is a microcessor (CPU) or a bus master
PCI device.
> I use viewdraw. I will eventually learn VHDL. I get more embarrassed each
> day about using schematics.
>
I guess I shouldn't start those Verilog vs. VHDL debate here,
but I personally think Verilog is somewhat a simpler language, and has
less learning curve compared to VHDL.
So, I will recommend learning Verilog,
But even for a PCI IP core design, I think you should use Verilog or
VHDL rather than schematics because HDL makes state machine design easy
compared to schematics.
Learning either HDL should save you a lot of time in the long run
compared to doing a PCI IP core in schematics.
At least, I cannot imagine myself doing a PCI IP core in schematics
because it will take much much more time.
However, Austin Franklin said some time ago that Xilinx's LogiCORE PCI
was done in schematics, and was pretty buggy when it was first released.
Austin's PCI IP core which Xilinx once considered buying it (or
licensing it) was also done in schematics according to him.
> I would love to get my PCI logic design working rather than using another.
> Having your own is very very flexible.
>
My PCI IP core has a flexible interface that can handle burst
transfers, and at least I know that the target part of it is fairly
stable, but the initiator (bus master) part still needs more work.
If still interested, let me know that (What happened to the plane ticket
thing?).
I am sure using a PCI IP core will save you many months of struggle to
get yours to work (Mine is also taking long long time to develop it.).
However, you will also learn a lot about PCI by doing your own PCI IP
core.
> I do not have a bus busy state. But I only start a transaction if the
> command is a memory read/write AND my address space is decoded. Shouldn't
> this be enough to prevent me from starting a transaction that is not for me.
>
I am starting to suspect that not having a bus busy state is the
reason why the card works most of the time, but fails sometimes.
My theory is that occasionally, the AD[31:0] and C/BE#[3:0]'s bit
pattern happens to be same as the address and command you are thinking
is not being utilized, and when that happens, your PCI IP core
mistakenly starts the transaction, leading to a crash because some other
device is still using the bus.
I came up with this theory when you said something like when a third
party PCI card is with your Spartan-II PCI card, the computer crashes.
It is possible that third party PCI card (Who made it?) is a bus master
device, and during the bus master transfer, it may output certain bit
patterns on AD[31:0] and C/BE#[3:0] that exactly matches your PCI card's
address and command.
PCI bus is a time multiplexed bus, so you need to have a bus busy state
to ignore the traffic on the bus when you know that the transaction is
not for you.
If you have a logic analyzer, you should be able to see when the thing
crashes.
In my case, I used Post P&R simulation extensively before burning a
Configuration PROM.
> >In PCI, FRAME# = 'L' and IRDY# = 'H' signals the start of a transaction,
> I think of the start of a transaction in another way. It is the first clock
> that FRAME# goes low. This is when I latch the command nibble and the
> address. I ignore IRDY# when making this determination. Shouldn't this be
> sufficient to prevent me from claiming a transaction in error ?
>
> Thanks again Kevin.
>
> Dan DeConinck
Again, PCI bus is a time multiplexed bus, so you cannot assume
that when FRAME# = 'L' is the only condition that signals an address
phase.
FRAME# and IRDY#'s meaning change depending on where you are in the
transaction.
Therefore, a bus busy state is important.
Kevin Brace
Article: 40856And those extra columns can make using the floorplanner a PITA with RPMs because of a bug in the floorplanner software. Basically, an RPM can't be placed so that it straddles a BRAM column in the floorplanner even though it is legal to do and accepted by the rest of the tools It can make the floorplanning a real fun time! Jan Gray wrote: > In base Virtex devices, there are two columns of block RAMs, one at the left > edge and one at the right. In Virtex-E there are four (V50E-V400E), six > (V600E-V1000E), or eight (V1600E-V3200E) columns of block RAMs. In block > RAM constrained designs, this makes all the difference. > > Jan Gray, Gray Research LLCArticle: 40857
Paul wrote: [snip] > Anyway I look forward to the book when it arrives here in England. > Its a bit of a shame its not featured at any of the major booksellers online > and only at www.vhdlcohen.com AFAIK Fatbrain: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0970539428&vm= Barnes & Noble: http://shop.barnesandnoble.com/bookSearch/isbnInquiry.asp?isbn=0970539428 -- Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systemsArticle: 40858
Should I post the Verilog code I wrote that instantiates it from XST as a public service to this newsgroup? I figured it out how to use it from ISE WebPACK + XST (I don't have access to FPGA Editor.), and it seems to work well in ModelSim XE-Starter with my own PCI IP core. However, I didn't feel like burning a Configuration PROM just for it, so I haven't tested it in a real computer though. Do people of this newsgroup have a problem me posting fairly long code with a constraint file? I honestly don't really like the idea that Xilinx has an upper hand over ordinary users, and they are the only ones who know how to use it. Kevin Brace (Typically, don't respond to me directly, and respond within the newsgroup.)Article: 40859
In article <u97jr0cosbpc33@corp.supernews.com>, austin@dar55kroom.com says... > > Out of curiosity, and not meaning to sound crass (me, no) but don't they > teach the use of capital letters, two spaces after a period, and a line > break between paragraphs in school these days? No, they teach creative spelling, and other feel-good notions. Spelling, phonics, and grammar are all deprecated, as is any sense of conventional layout, of course. BillArticle: 40860
HDL Chip Design, Writting TestBench, Real Chip Design Who can help me ? My email box is big enough for receieve this boos .Article: 40861
who can introduce some examples and concept (books/link)about pipeline?Article: 40862
> I certainly hope they don't teach two spaces after a period. > That's a typographical no-no that went out with the typewriter. Hi Pete, Says who (I mean in an authoritative position WRT type written "correctness"...like the MLA Style Sheet....remember that?)? And I ask that seriously. At least to me, it's a heck of a lot more readable with two spaces...which is why I believe "they" did it in the first place. AustinArticle: 40863
On Sat, 16 Mar 2002 09:47:22 +0000, Rick Filipkiewicz <rick@algor.co.uk> wrote: >The IOB packing problem comes up on this NG many times so you could try an >archive search but a brief summary, for Virtex/Spartan2 is: > >o No logic before an input FF. > >o No logic after an output FF - not even an inverter. > >o No feedback from an output FF. (*) You can get feedback from an output FF quite easily - the feedback comes back through the ibuf. It's a bit tricky to specify in HDL though, as you need to convince the tool that this pin is bidirectional. 1. The port mode should be inout (VHDL) 2. The output driver needs a tristate control, but not a trivial one that the tool can optimise out, yet something that will always be on during operation. Gsr works well for this (if you can handle the output pins going hiZ during reset). It's not something you need often. I've used it for connections to a logic analyser, when I wanted the signals on the pins (input and output) to be sampled at the same time. Regards, Allan. >For BiDirs (almost all PCI signals are such). > >o A common clock. > >o A common initialisation signal. The function - async/sync set/reset - of this >signal can differ between the input and output FFs. The easiest way in which >this can be broken is to have one FF with an init condition and the other >without (+). > >I've never really had to force the use of the tri-state FF so I'm not sure what >the exact rules for it are. > >Note that even if you think you are keeping to the rules synthesis tools can >break them behind your back esp. (*) & (+). > >Having kept to all these rules its then best to use the `-pr b' flag to MAP >which tells it to IOB pack FFs if at all possible. You can then use the >`IOB=FALSE' attribute to exclude ones you don't want packed. Its rare that >you'll need to do this but I can give you my example: The incoming IO data bus >feeds 3 registers, one "ordinary" one going into the main data path (in the >IOB) and 2 async clocked ones for IDE UDMA (not in the IOB). > >Now the hard part: Finding the ones that should have been packed but weren't >... > >Article: 40864
man...tough crowd. first my credibility is challenged, and then my typographical style. next post will be in all capitals with 5 spaces after the period. strut911Article: 40865
Mike Treseler <tres@tc.fluke.com> wrote in message news:<3C93BE9C.87F44C40@tc.fluke.com>... > strut911 wrote: > > > i just wanted to give everyone a heads up on my experience with this > > book. if you want to learn more about chip/fpga design and > > verification, at least the way it is done by professionals, i > > recommend this book. > > I would find this review much more credible > if Mr. Strut911 from hotmail.com > would identify himself. > > -- Mike Treseler ouch...just trying to help. disregard it if you feel uncomfortable. strut911Article: 40866
Hi Rick. ThankX for your answer. Can you please elaborate on the 'SPEEDPRINT' utility ? Is it a part of the xilinx package ? ThenkX again. Nahum. Rick Filipkiewicz <rick@algor.co.uk> wrote in message news:<3C91A1E7.C179FA9A@algor.co.uk>... > Nahum Barnea wrote: > > > Hi. > > Xilinx tradionally publish only max values for the clock to out > > delays. > > > > This isn't quite correct. Although quite often the early datasheets don't > publish min delays when a part family matures a little they do tend to > appear. Its even possible to do a min timing simulation. > > > > > I remember that there is an application note that say that the min clock > > to out value can be taken as 1/3 'rd of the max value (or 1/4 'th if > > you are a conservative person). > > > > Check out the `SPEEDPRINT' utility. There's a min timing flag and it will > tell you either the min timings or a message saying they are not available. > > Its some time since I dumped the min & max timings and did a comparison but > IIRC the ratio for the 1000001 timing values for original Virtex was, > overall, about ~ 1/3.Article: 40867
Christopher Saunter <Christopher.Saunter@durham.ac.uk> wrote: > What I would like to do is export the schematic to a standard (eg WMF) > vector format, so I can easilly embed it in documents, and edit it as a > vector file. I would have thaught this would be a simple option to add to > SC programs, but... Print to PostScript, convert to EPS? Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 40868
Nahum Barnea wrote: > Hi Rick. > ThankX for your answer. > Can you please elaborate on the 'SPEEDPRINT' utility ? > Is it a part of the xilinx package ? > > ThenkX again. > Nahum. > > Its certainly part of the full, paid for, ISE package. I don't know about WebPACK. Its documented in the Development System Reference Guide.Article: 40869
Eric Crabill wrote: > I think you can find a summary of what was packed and what was not > by looking towards the tail end of the mapper report (whatever.mrp). > > For each IOB/Pin, it lists the use of the INFF, OUTFF, or ENBFF. > > Eric > > I should have elaborated: By "hard part" I mean detecting automatically that an FF that should be packed wasn't, generating an error message, and stopping the build process. I had a script that had worked fine since I first came across the IOB packing problem ... and then the $£*&$%'s changed the MAP report format for 4.1i !?Article: 40870
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> wrote: > I guess the XST is not the only synthesis tool that has this > problem. I wouldn't say it's a problem. Generally speaking it is a helpful thing for it to do. It makes the code look better if you only have a single output enable signal, rather than manually creating N of them. It's a fact of life that if you want something different from the obvious behaviour, you have to fight the tools for it. The tool thinks it is optimising the design for you. But the tools just aren't very good at optimising really high speed stuff. A while back I was having trouble getting a design routed, so I started fiddling with the manual fan-out control. I changed the value and looked at the tool's speed estimate. I found an optimal value according to the tool -- but the optimal value at route time was different again. So I don't pay too much attention to the estimated clock speeds. The automatically duplicated signals are only half as effective as they could be due to register ordering performed by Xilinx MAP. The synth tool companies need to do something to work around this ASAP. In the longer term, Xilinx urgently needs to provide an attribute that can be applied to signals to disable this behaviour. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 40871
Allan Herriman wrote: > On Sat, 16 Mar 2002 09:47:22 +0000, Rick Filipkiewicz > <rick@algor.co.uk> wrote: > > >The IOB packing problem comes up on this NG many times so you could try an > >archive search but a brief summary, for Virtex/Spartan2 is: > > > >o No logic before an input FF. > > > >o No logic after an output FF - not even an inverter. > > > >o No feedback from an output FF. (*) > > You can get feedback from an output FF quite easily - the feedback > comes back through the ibuf. > > It's a bit tricky to specify in HDL though, as you need to convince > the tool that this pin is bidirectional. > 1. The port mode should be inout (VHDL) > 2. The output driver needs a tristate control, but not a trivial one > that the tool can optimise out, yet something that will always be on > during operation. Gsr works well for this (if you can handle the > output pins going hiZ during reset). > > It's not something you need often. I've used it for connections to a > logic analyser, when I wanted the signals on the pins (input and > output) to be sampled at the same time. > > Regards, > Allan. > I use that trick as well. The `Rule' really relates to those times when your wonderful synth tool has fed back an output FF behind your back. Typically it goes like this. In some state machine: in state A: my_out_ff is optionally turned on in states B,C: my_out_ff holds its value. in state D: my_out_ff gets turned off What I've seen Synplify do is to not use the clock enable at B,C but wire the `my_out_ff' value through LUTs into the D input.Article: 40872
"Austin Franklin" <austin@dar55kroom.com> writes: > > > i just wanted to give everyone a heads up on my experience with this > > > book. if you want to learn more about chip/fpga design and > > > verification, at least the way it is done by professionals, i > > > recommend this book. > > > > I would find this review much more credible > > if Mr. Strut911 from hotmail.com > > would identify himself. > > > > -- Mike Treseler > > Same thought came to my mind....though he's posted in comp.arch.fpga > before... > > Out of curiosity, and not meaning to sound crass (me, no) but don't they > teach the use of capital letters, two spaces after a period, and a line > break between paragraphs in school these days? Only in US schools, I believe. Here, it is one space and no line break. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 40873
Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com> writes: > I honestly don't really like the idea that Xilinx has an upper hand over > ordinary users, and they are the only ones who know how to use it. Well, they make the chip, so I guess it's hard to imagine theyh NOT having an upper hand. Homann -- Magnus Homann, M.Sc. CS & E d0asta@dtek.chalmers.seArticle: 40874
emanuel stiebler wrote: > Rick Filipkiewicz wrote: > > > > o The first question has to be - have I been given a load of BS about > > WinNT not running on the XP ? > > Probably ;-) > The problem is that the guy who installs the O/S on our boxes is a firm believer in the wonders of Windoze and accepts potential nonsense like the above. I really should have bitten the bullet and installed NTSP6A myself just to see what happened. > > > Under NT the `CPU' and `real' times are never more than a minute or so > > apart on a quiet machine, even with PAR set to low priority. The > > difference being accounted for, I'd guess, by file IO. > > You're using palain w2000 or already sp2 ? > Certainly SP2 and probably SP3. What's the Win2K equivalent of `winvers' ? > > > > o When I run ModelSim I keep most of the project stuff, scripts, etc on > > a Unix box and export them to the PC via Samba. Under WinNT it made very > > little difference when I did `Open Project' where the .mrp project file > > was. Trying this last night under Win2K and it took ~10min just to load > > the project. I hate to think what's going to happen when it tries > > loading an SDF. > > Check the version of samba you're using. The versions before 2.1 (IIRC) > had big problems with w2000. (mostly performance) > > Actual version of samba is 2.2.3a (from february ?) > Thanks I'll check that out. > > cheers, > > P.S. Sitting in the same boat. Downgraded my system from nt4sp6a to > w2000sp2, > but on a P4. As at your place, all my design files are on a box I > trust. In my case, at home, the rock solid box is a 1995 PI running BSDI 4.2 Unix at the astounding clock speed of 150MHz with the huge memory size of 64MB. In terms of the ability to interact i.e. type things in emacs, with some heavy processes running in the background, it completely blows away the super Wintel boxes. This also applies when it starts swapping. NT's (and no doubt Win2K's) performance nosedives dramatically at the slightest hint whereas BSD Unix degrades fairly gracefully. I've been told that Linux is pretty poor in this area as well. Ironically in some ways its a real shame that memory prices got so low - otherwise the pressure to run memory hungry EDA tools on Unix would have become irresistable.
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