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
For those following this thread: This turned out to be something much less sinister: the LOCKED output of the first DCM must be inverted and sent to the RESET input fo the second (cascaded) DCM. The only point in bringing this up here is that generally speaking as an IC Designer, everything looks like an IC issue to be (when you are a hammer, everything looks like a nail). Of course, the hotline does a great job (solving 99.99% of cases quickly), but the occasional case does get stuck (for no fault of anyone), and in this case, I looked at the HDL code, and saw the problem immediately (only because it bit me once, well maybe twice). Austin Rod Barman wrote: > In our case the variable phase shift works great but the > DCMs sometimes stop running after only a few cycles. The LOCK output > remains high but the clock output stops. We have 5 DCMs we'd like > to use in this fashion. > > We also looked at the status bits but they don't seem to tell us much. > > I've opened a webcase on the issue. > > There is an interesting answer record #13756 which probably everyone > using DCMs should read. > > --rod. > > Yanick wrote: > > > > Austin, > > > > This is an important issue for us that we need to solve, this is why I > > am asking the group looking for similar experiences and a hopefuly, a > > solution. > > > > The PS=14 is by configuration, not obtained using the DCM PS > > interface. Though, we have a dcm_controller module that allows us to > > change the phase-shift. We probed the DCM PS interface as well as the > > lock signal with a logic analyzer and everything looks good, as > > expected. > > > > This is not an early ES device, as indicated by the JTAG code, so that > > errata should not apply anyway. > > > > Regards, > > > > Yanick > > > > Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3D3729C9.482754BA@xilinx.com>... > > > Yanick, > > > > > > Please open a case with the hotline. Typical problems we have seen are: > > > > > > 1) not implementing the correct interface with PSEN, PSINC/DEC, PSCLK > > > > > > 2) unit stops inc (or dec) due to the ES issue (fixed in susequent masks > > > and production) This is easy to see, because PSDONE goes low, and never > > > returns to high (indicating the internal state machineis stuck). > > > > > > Also please contact your FAE, > > > > > > Austin > > > > > > Yanick wrote: > > > > > > > Hi, > > > > > > > > We've done some tests in the lab on a XC2V6000 and got results that > > > > were not the same using fixed versus variable phase-shift. I first > > > > measure the clock-to-out for a signal that is FF in the IOB and that > > > > is clocked using a DCM with variable phase-shift = 14 at 175 MHz. I > > > > then changed the mode to fixed in fpga_editor and tied all the DCM's > > > > PS inputs to logic_0 keeping the same PS=14 and got slightly different > > > > clock-to-out. > > > > > > > > The thing is that our circuits work well when fixed but are erratic > > > > when in variable mode. > > > > > > > > Why does PS=14 lead to a different shift ? > > > > > > > > Best regards, > > > > > > > > YanickArticle: 45351
Using an FPGA for the processing intensive stuff can dramatically improve
performance and may also reduce power, BUT you won't do it with a direct port of
your C code even if you get one of the C to hardware compilers to work for you.
FPGA design is digital logic design, if you try to treat it as a software design
you are doomed to fail. That said, the gains achievable with an FPGA come from
the ability to do the operations in your algorithm in parallel. Often, it
requires taking an different approach to the algorithm in order to map it into
hardware. If you are not familiar with hardware DSP, you might consider using
an outside provider with that expertise to do or help you with the FPGA design,
or at least to map the design into a hardware block diagram for you.
paul hill wrote:
> Hi,
>
> I'm currently trying to spec a project that needs to do some serious video
> processing (mpeg2 encoding or similar) in a mobile (wearable) environment.
> i.e. battery powered.
>
> Does anyone have any opinion on what dsp platform would be suitable. People
> have been talking about xilinx chips or something similar. However, I'm
> most familiar with DSP programming on ti processors (such as C67xx) but
> would an implementation using ti processors take too much power and be too
> slow.
>
> Ideally I would like to reuse the c-code that I have already for the mpeg2
> codec but with xilinx chips this would not be possible.
>
> Any ideas anyone?
>
> Paul Hill
--
--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: 45352Running into a recurring theme where code that worked fine in FPGA Express version 3.6.1 (and I mean the actual FPFAs worked in the system) generates warnings in FPGA Compiler II Version 3.7.1. It's both "net has no load" and "net has no driver" warnings for a scattering of nets. When you find the nets on the schematic, they look fine, so the warnings appear to be farcical. This is VHDL that functioned perfectly under 3.6.1. Anyone else run into this? The nets are all in the same component, but for the life of me I can't see anything amiss in the code. This was functional code. The physical circuit works.Article: 45353
Which of these methods do you like? What if design is large? what if small? Comments? FYI: sites of info http://www.cu.edu/~irm/about_irm/self_study/96_method.html http://www.hyperthot.com/pm_sdm.htm http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/watersluice.html Water_sluice methodology http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/sluice.gif ---------------------------------------------------------------------------- Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 http://www.vhdlcohen.com/ vhdlcohen@aol.com Author of following textbooks: * Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 * Component Design by Example ", 2001 isbn 0-9705394-0-1 * VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 * VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 ------------------------------------------------------------------------------Article: 45354
Thanks for the update.
Bill
"Austin Lesea" <austin.lesea@xilinx.com> wrote in message
news:3D388580.954B7AB0@xilinx.com...
> For those following this thread:
>
> This turned out to be something much less sinister: the LOCKED output of
the first DCM must be
> inverted and sent to the RESET input fo the second (cascaded) DCM.
>
> The only point in bringing this up here is that generally speaking as an
IC Designer, everything
> looks like an IC issue to be (when you are a hammer, everything looks like
a nail).
>
> Of course, the hotline does a great job (solving 99.99% of cases quickly),
but the occasional case
> does get stuck (for no fault of anyone), and in this case, I looked at the
HDL code, and saw the
> problem immediately (only because it bit me once, well maybe twice).
>
> Austin
>
> Rod Barman wrote:
>
> > In our case the variable phase shift works great but the
> > DCMs sometimes stop running after only a few cycles. The LOCK output
> > remains high but the clock output stops. We have 5 DCMs we'd like
> > to use in this fashion.
> >
> > We also looked at the status bits but they don't seem to tell us much.
> >
> > I've opened a webcase on the issue.
> >
> > There is an interesting answer record #13756 which probably everyone
> > using DCMs should read.
> >
> > --rod.
> >
> > Yanick wrote:
> > >
> > > Austin,
> > >
> > > This is an important issue for us that we need to solve, this is why I
> > > am asking the group looking for similar experiences and a hopefuly, a
> > > solution.
> > >
> > > The PS=14 is by configuration, not obtained using the DCM PS
> > > interface. Though, we have a dcm_controller module that allows us to
> > > change the phase-shift. We probed the DCM PS interface as well as the
> > > lock signal with a logic analyzer and everything looks good, as
> > > expected.
> > >
> > > This is not an early ES device, as indicated by the JTAG code, so that
> > > errata should not apply anyway.
> > >
> > > Regards,
> > >
> > > Yanick
> > >
> > > Austin Lesea <austin.lesea@xilinx.com> wrote in message
news:<3D3729C9.482754BA@xilinx.com>...
> > > > Yanick,
> > > >
> > > > Please open a case with the hotline. Typical problems we have seen
are:
> > > >
> > > > 1) not implementing the correct interface with PSEN, PSINC/DEC,
PSCLK
> > > >
> > > > 2) unit stops inc (or dec) due to the ES issue (fixed in susequent
masks
> > > > and production) This is easy to see, because PSDONE goes low, and
never
> > > > returns to high (indicating the internal state machineis stuck).
> > > >
> > > > Also please contact your FAE,
> > > >
> > > > Austin
> > > >
> > > > Yanick wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > We've done some tests in the lab on a XC2V6000 and got results
that
> > > > > were not the same using fixed versus variable phase-shift. I first
> > > > > measure the clock-to-out for a signal that is FF in the IOB and
that
> > > > > is clocked using a DCM with variable phase-shift = 14 at 175 MHz.
I
> > > > > then changed the mode to fixed in fpga_editor and tied all the
DCM's
> > > > > PS inputs to logic_0 keeping the same PS=14 and got slightly
different
> > > > > clock-to-out.
> > > > >
> > > > > The thing is that our circuits work well when fixed but are
erratic
> > > > > when in variable mode.
> > > > >
> > > > > Why does PS=14 lead to a different shift ?
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Yanick
>
______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
<><><><><><><> The Worlds Uncensored News Source <><><><><><><><>
Article: 45355I have an old design that I need to update but have lost the dongle for my old xilinx development system. I still have the software I just don't have the dongle. Does anyone have one they want to sell? Does anyone have a full development system from then they want to part with? My design uses an XC3030 Thanks Todd ( todddavid@excite.com )Article: 45356
You're right. There are a lot of postings. Too bad they're all bogus. I sorted DICE, HEADHUNTER, and HOTJOBS. Printed out every job posting that had the words FPGA, ASIC, VHDL, or Verilog and were in the 3 area codes around me. I called them all. The unanamous response was: "I'm sorry, that's not a current posting." That's right, 100% of them were bogus. 100% Sigh. On Fri, 19 Jul 2002 07:49:48 -0400, "Martin Guibert" <guibert@REMOVE_MEistop.com> wrote: >Than how come that we see tons of postings about jobs in the San Jose area >for IC / FPGA designers? (and most of the US?) > >You guys are lucky, there are tons of job postings for you. Here in Ottawa, >there's nothing!! > > > >"Spam Hater" <spam_hater_7@email.com> wrote in message >news:3d37a61a.2056645@64.164.98.7... >> On Fri, 19 Jul 2002 03:33:30 GMT, bbdjsk <bbd@ksl.com> wrote: >> >> That's putting it mildly. >> >> >The slump seems to have hit the San Jose area (California's "Silicon >Valley") pretty hard. >> > >Article: 45357
On 19 Jul 2002 16:48:05 -0700, vhdlcohen@aol.com (ben cohen) wrote: >Which of these methods do you like? >What if design is large? what if small? Comments? > >FYI: sites of info >http://www.cu.edu/~irm/about_irm/self_study/96_method.html >http://www.hyperthot.com/pm_sdm.htm >http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/watersluice.html > >Water_sluice methodology >http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/sluice.gif > >---------------------------------------------------------------------------- >Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 >http://www.vhdlcohen.com/ vhdlcohen@aol.com >Author of following textbooks: >* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 >* Component Design by Example ", 2001 isbn 0-9705394-0-1 >* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1 >* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115 >------------------------------------------------------------------------------ Sounds like software methodologies are taking over logic design, so that we can now have FPGA's of the same quality, speed, and density of, say, Outlook for Windows. JohnArticle: 45358
suchitra wrote: > hello friends > i am programming cpld's for the first time. > i have a jtag cable from insight. > i have prepared a simple regulated power supply using 12v 500mA > transformer bridge rectifier of 4007 and two lm 317 to extract two > supplies of 3.3v and 5 v needed for cpld and jtag cable respectively. > but when ever i connect the jtag supply my supply voltage drops..... i > have checked all the connection but didnot find any short circuit or > wrong connection ..... > can any one tell me where might be the problem and how to check if the > jtag cable is intact i have webpack and am suing the impact software > for programming. > Try measuring the current. you're dropping a lot of power from 12 to 3.3V. You might want a 9V regulator to feed the 5, and then use the 5 to feed the 3.3. I'm not sure how much you need for the cpld jtag signals, but add up worse case and make sure you're not exceeding it. Patience, persistence, truth, Dr. mike -- Mike Rosing www.beastrider.com BeastRider, LLC SHARC debug toolsArticle: 45359
Hi comp.arch.fpga'lers, I am writing from Singapore, which is equally (if not worst) affected by the tech slump. My company, NEC Mobile Communications Development, has just been liquidated after 5 years in operation. We work like contractors for the Japan office, developing hareware (ASIC/FPGA/system) and software for the 3G base station. I believe the news came as a shock to all of us. It puts 20 over software engineers from India and China, and another 20 over hardware engineers out of job. So far, only a couple of us have job offers (with pay cut), the rest are still looking. The job market now for FPGA/ASIC designers is really very bad compared to say, year 2000, where companies would advertise for these positions every week. Although I have a fair amount of experience with FPGA, there is little chance for us to startup on our own. Unlike the US, companies here are not out-sourcing. They would rather buy tools and hire people to do in-house development. I don't know how long this slump is going to be. Does anybody have a clue? LC Martin Guibert <guibert@REMOVE_MEistop.com> wrote in message news:1027046697.479172@ip195.istop.com... > Hello all... > > I'm a senior FPGA designer with experience in telecom and 3D graphics and > also as an ASIC designer and FPGA team leader. I'm located in Ottawa, > Canada (for those who don't know) but recently got laid off due to the high > tech slump here in Canada so I'm currently looking for work. No luck so > far... the market is really bad (and it's the summer!) and salaries have > dropped quite a bit up here. > > I was wondering how's the job market for senior FPGA designers in the rest > of Canada and USA? What about other countries? > > Do a lot of you work remotely? > > Thanks! > > Martin > >Article: 45360
Hi, there, I was just wondering if SpartanII JTAG can be connected with other JTAG device. For example, in my design, there are JTAG devices of SpartanII FPGA, CPLD, PROM and ARM processor. Can I serially connect them together as standard way? If yes, will there be any problem when using JTAG to programme SpartanII? Is there any reference design available? Thanks a lot. DavidArticle: 45361
> Sounds like software methodologies are taking over logic design, so > that we can now have FPGA's of the same quality, speed, and density > of, say, Outlook for Windows. Woohoo! So now, when a design doesn't fit in a chip, all we have to say is "buy a bigger / faster FPGA" instead of worrying about fitting the design in the device! MartinArticle: 45362
Hello, all, I noticed that Xilinx Vertex-II provide 18*18 multipliers, which introduce a lot of delays. Can I generate a more efficient 16*16 multiplier, which is my target, and give me a shorter delay? Another question is how to determine the clock speed for the Vertex-II embedded multiplier? Any advice or help is greatly appreciated! HuaArticle: 45363
Dear Laurent:
Neither WebPACK, ISE or Modeltech understands the undefs in
wb_addr.mux.v (line 165), wb_slave.v (line 1033), pci_tpram.v (line 308), or
wb_tpram.v (line 310). I found that those are not needed if you have defined
FPGA, XILINX & GUEST in pci_user_constants.v and the core is currently
running on my desk in a VirtexE2000 chip at 33Mhz. I dont understand your
multisource signal comment, I have not seen that before and I have been
working intensely with this code for a couple of months now. Please describe
a bit more completely which signal you are having a multisource issue with
and I will try to help you out.
You might also find the opencore newsgroup useful as Miha, myself and a
number of others currently working with this core are there all the time.
The folks here may or may not be that interested in opencore, dont know.
Charles Krinke
"Kevin Brace" <killspam4kevinbraceusenet@killspam4hotmail.com> wrote in
message news:ah76q5$fe3$1@newsreader.mailgate.org...
> I am not sure what is causing your problem, but unless an internal
> tri-state buffer is used, you cannot connect two wires together, and
> connect that wire to a FF (or a LUT).
> If what you are saying is true, and `undef is the only reason that's
> causing the problem you described, you will want to modify the code so
> that it won't be tying two wires together.
> It's my own opinion, but the authors of Opencores.org PCI IP core seem
> to have too many submodules in their design, and furthermore, they tend
> to keep changing signal names throughout the design.
> Those problems tend to make it really hard to follow what is going on in
> the design in case someone else has to make modifications to fix
> problems.
> I assume you ended up going back to WebPACK ISE 3.3WP8.0's XST,
> but I believe that version's XST has a bug that causes XST to go into an
> infinite loop when synthesizing some designs.
> The newer version of XST (XST since ISE WebPACK 4.1) shouldn't have that
> problem.
> However, not all designs being synthesized will exhibit the infinite
> loop problem you experienced.
> I believe the authors of Opencores.org PCI IP core used FPGA Express to
> synthesize the design.
> If you have access to it, you may want to use that, but if you are a
> poor ISE WebPACK user like myself, you are stuck with XST.
>
>
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)
>
>
>
> BROTO Laurent wrote:
> >
> > Hi all,
> >
> > I've downloaded the OpenCore's PCI IP Core.
> > I'm working with WebPack 4.2.03 and I've got problem when I want
synthetize
> > the project.
> >
> > XST (the compiler) doesn't understand the `undef directive.
> > When I remove this directive, I've got multisource in signal xyz.
> >
> > Therefore, I've downloaded WebPack 3.8 to have the "Resolution Style"
> > option.
> > With this version, I can begin to compile the PCI Bridge, but 12 hours
after
> > beginning, it's no yet finish.
> >
> > So, do you know how can I should synthetize this project ?
> >
> > Thanks a lot,
> >
> > Laurent
Article: 45364ben cohen wrote: > Which of these methods do you like? > What if design is large? what if small? Comments? If the design is easily fully definable, "waterfall". One of the nice things about this method is that: once you have defined the problem, an experienced designer can give a schedule that will be fairly close. Management always likes getting a schedule that you will come close to. If the design isn't definable, a method somewhat like "water_sluice". Some problems just can't be defined up front. They are too complex, or not well enough understood. Almost as interesting a question might be: The software world has been dealing with larger and more complex problems for years. As both FPGAs and ASICs get larger, the hardware design process is able to attack more complex problems. The mistakes made by software design teams in the past have been and are going continue to be repeated by hardware designers in these more complex designs. Why is there widespread hostility to learning from the software design world? -- Phil HaysArticle: 45365
>Which of these methods do you like?
>What if design is large? what if small? Comments?
>FYI: sites of info
>http://www.cu.edu/~irm/about_irm/self_study/96_method.html
>http://www.hyperthot.com/pm_sdm.htm
>http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/watersluice.html
>
>Water_sluice methodology
>http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/sluice.gif
--------------------
> Sounds like software methodologies are taking over logic design, so
> that we can now have FPGA's of the same quality, speed, and density
> of, say, Outlook for Windows.
> John
-----------------------
<Woohoo!
So now, when a design doesn't fit in a chip, all we have to say is
"buy a
bigger / faster FPGA" instead of worrying about fitting the design in
the
device!
Martin>
<If the design is easily fully definable, "waterfall". One of the
nice
things about this method is that: once you have defined the problem,
an
experienced designer can give a schedule that will be fairly close.
Management always likes getting a schedule that you will come close
to.
-------------------------
<If the design isn't definable, a method somewhat like "water_sluice".
Some problems just can't be defined up front. They are too complex,
or
not well enough understood.
Almost as interesting a question might be:
The software world has been dealing with larger and more complex
problems for years. As both FPGAs and ASICs get larger, the hardware
design process is able to attack more complex problems. The mistakes
made by software design teams in the past have been and are going
continue to be repeated by hardware designers in these more complex
designs. Why is there widespread hostility to learning from the
software design world?
Phil Hays>
--------------------------------------
BEN: Agree with Phil. Also, HDL is software, with understanding of
hardware. However, I know of organizations that use the spiral method
with fpga's. The cycle is:
Rough req -> RTL (poorly documented, of course)
-> synthesis -> board test (no TB, no simulation // not needed!)
-> back to top, or to RTL.
Requirements are refined as the project goes on, and may be documented
on Note Pads/ white boards, but sometimes in WORD.
The biggest issue with the spiral method is that it's almost endless,
because there is no criteria as to when you're done. The cycle
described above has been known to continue till the last minute for
last updates/fixes.
Curious to know if others had good experiences with the spiral method.
Also, regardless of the methodology, how good is your documentation
(req, HDL, scripts)?
Waterfall method is good, but changes to requirements becomes a big
issue because you have to go back to the top of the waterfall.
---------------------------------------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdlcohen@aol.com
Author of following textbooks:
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
0-7923-8115
------------------------------------------------------------------------------
Article: 45366On Sat, 20 Jul 2002 16:44:46 GMT, Phil Hays <SpamPostmaster@attbi.com> wrote: >Why is there widespread hostility to learning from the >software design world? Because classicly engineering design has been a stable, dependable discipline, and software has always been a nasty hairball and is getting steadily worse. The popular mantra 'software will always have bugs' is believed by virtually all programmers, so is self-fulfilling. JohnArticle: 45367
John Larkin wrote: > > On Sat, 20 Jul 2002 16:44:46 GMT, Phil Hays <SpamPostmaster@attbi.com> > wrote: > > >Why is there widespread hostility to learning from the > >software design world? > > Because classicly engineering design has been a stable, dependable > discipline, and software has always been a nasty hairball and is > getting steadily worse. The popular mantra 'software will always have > bugs' is believed by virtually all programmers, so is self-fulfilling. > > John My two cents on that. The real issue is not software vs. hardware. The problem of having bugs in a "finished" system is a matter of complexity vs. development effort. Something as complex as an OS, for example, will always have bugs, not because it is software, but because it is very complex. The amount of effort that would need to be expended to make it "bug free" would be enormous and it would not be possible to verify that it was "bug free". Many of the hardware systems I have seen are not "bug free". I don't believe for a second that my PC has no problems in the hardware. I do belive that they have been reduced to an acceptable level and are largely covered up by the software bugs. But this is mainly because the software is much more complex and changes much more rapidly adding new bugs. If we all continued to use Windows 95 and Microsoft continued to make patches for bug fixes, I expect we would start seeing a lot more hardware problems and eventually see very few software problems. But then Bill would ultimately become very poor. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 45368
Hi Phil, Phil Hays wrote: > The software world has been dealing with larger and more complex > problems for years. As both FPGAs and ASICs get larger, the hardware > design process is able to attack more complex problems. The mistakes > made by software design teams in the past have been and are going > continue to be repeated by hardware designers in these more complex > designs. Why is there widespread hostility to learning from the > software design world? Well, obviously we should learn from software methods where applicable. On the other hand, every now and then, we encounter attempts to force software methodologies on hardware design. As an example, some code review methods suggest to go through the code on a line by line basis. This will make a certain amount of sense if your formal language is largely sequential, but is not particularly suitable for parallel languages. I think to first review block diagrams, interface definitions and state machines, then compare whether the code matches the spec makes more sense and will result in a higher number of errors being found. Of course on the project I was thinking of, we were also adviced to go through design documents on a line by line basis, resulting in "review" meetings which created reports about spelling errors... Well I can laugh about it now.... :-/ The other objection I have is that there is a certain assumption that software methods are more advanced than hardware methods. Often based on the idea, that software is designed on a higher level of abstraction than hardware, and must therefore be "higher-level". I believe though, when it comes to design quality, your average hardware project uses much more advanced methods, than your average software project. E.g. complex testbenches, which take more time to code than the actual chip, script based regression tests, third-party testbench components etc. As design teams grow, some software methods to coordinate large teams become very interesting. E.g. revision control, bug tracking, build systems/strategies. Whether we can learn from software here is another matter: I have the impression that e.g. revision control is a standard on large hardware projects, already. So in this case it's just too late, we've already learned that. :) Anyway, I have the impression that a lot of engineers have had some negative experiences with unsuitable software methods forced on hardware projects, like the one I described above. So hearing about another one might immediately trigger a certain "not again" feeling... Cheers Stefan -- Stefan Doll, München, Germany http://www.stefanVHDL.comArticle: 45369
I have not seen the code, but it may be that when the undef is removed some code is being seen that should be hidden and two different versions of the same assignment statement are being used. Just a guess. Can you check the code and/or post some from near the errors? Especially anything using a def, ifdef or the like. cfk wrote: > > Dear Laurent: > Neither WebPACK, ISE or Modeltech understands the undefs in > wb_addr.mux.v (line 165), wb_slave.v (line 1033), pci_tpram.v (line 308), or > wb_tpram.v (line 310). I found that those are not needed if you have defined > FPGA, XILINX & GUEST in pci_user_constants.v and the core is currently > running on my desk in a VirtexE2000 chip at 33Mhz. I dont understand your > multisource signal comment, I have not seen that before and I have been > working intensely with this code for a couple of months now. Please describe > a bit more completely which signal you are having a multisource issue with > and I will try to help you out. > > You might also find the opencore newsgroup useful as Miha, myself and a > number of others currently working with this core are there all the time. > The folks here may or may not be that interested in opencore, dont know. > > Charles Krinke > > "Kevin Brace" <killspam4kevinbraceusenet@killspam4hotmail.com> wrote in > message news:ah76q5$fe3$1@newsreader.mailgate.org... > > I am not sure what is causing your problem, but unless an internal > > tri-state buffer is used, you cannot connect two wires together, and > > connect that wire to a FF (or a LUT). > > If what you are saying is true, and `undef is the only reason that's > > causing the problem you described, you will want to modify the code so > > that it won't be tying two wires together. > > It's my own opinion, but the authors of Opencores.org PCI IP core seem > > to have too many submodules in their design, and furthermore, they tend > > to keep changing signal names throughout the design. > > Those problems tend to make it really hard to follow what is going on in > > the design in case someone else has to make modifications to fix > > problems. > > I assume you ended up going back to WebPACK ISE 3.3WP8.0's XST, > > but I believe that version's XST has a bug that causes XST to go into an > > infinite loop when synthesizing some designs. > > The newer version of XST (XST since ISE WebPACK 4.1) shouldn't have that > > problem. > > However, not all designs being synthesized will exhibit the infinite > > loop problem you experienced. > > I believe the authors of Opencores.org PCI IP core used FPGA Express to > > synthesize the design. > > If you have access to it, you may want to use that, but if you are a > > poor ISE WebPACK user like myself, you are stuck with XST. > > > > > > > > Kevin Brace (In general, don't respond to me directly, and respond > > within the newsgroup.) > > > > > > > > BROTO Laurent wrote: > > > > > > Hi all, > > > > > > I've downloaded the OpenCore's PCI IP Core. > > > I'm working with WebPack 4.2.03 and I've got problem when I want > synthetize > > > the project. > > > > > > XST (the compiler) doesn't understand the `undef directive. > > > When I remove this directive, I've got multisource in signal xyz. > > > > > > Therefore, I've downloaded WebPack 3.8 to have the "Resolution Style" > > > option. > > > With this version, I can begin to compile the PCI Bridge, but 12 hours > after > > > beginning, it's no yet finish. > > > > > > So, do you know how can I should synthetize this project ? > > > > > > Thanks a lot, > > > > > > Laurent -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 45370
Hi, when I use the new core of xfft_1024_v10 to do a 64-point FFT, I found that the performance of the core is different from what the datasheet says. The datasheet says that even if START is not asserted again, XN_INDEX is going to keep counting from 0 to N-1 for 2N more clock cycles(on page 6). But i found in simulation that XN_INDEX is going to keep counting 3N more clock cycles. That means I can not pulse START during the course of unloading output data, but i want to do the separate fames of data FFT every 240 clock, how can I do? Another problem of this core is that if I use XST to synthesize, the result is wrong(the overflo turn to state of X when computing). When using synplify,the result is correct when the clock frequency less than 60Mhz, if the clk frequency more than 60MHz, the result is wrong just like when using XST, why?Article: 45371
On Sat, 20 Jul 2002 14:20:05 -0400, rickman <spamgoeshere4@yahoo.com> wrote: >John Larkin wrote: >> >> On Sat, 20 Jul 2002 16:44:46 GMT, Phil Hays <SpamPostmaster@attbi.com> >> wrote: >> >> >Why is there widespread hostility to learning from the >> >software design world? >> >> Because classicly engineering design has been a stable, dependable >> discipline, and software has always been a nasty hairball and is >> getting steadily worse. The popular mantra 'software will always have >> bugs' is believed by virtually all programmers, so is self-fulfilling. >> >> John > >My two cents on that. The real issue is not software vs. hardware. The >problem of having bugs in a "finished" system is a matter of complexity >vs. development effort. Something as complex as an OS, for example, >will always have bugs, not because it is software, but because it is >very complex. The amount of effort that would need to be expended to >make it "bug free" would be enormous and it would not be possible to >verify that it was "bug free". > Sure, complex systems are more prone to bugs. That's why I like to design deep embedded systems, where I can see and control everything and I don't have to try to learn 2400 weird API calls or try to interpret a purchased IP module with 19000 lines of (generally uncommented) VHDL. But I think that a lot of popular design methods add untold layers of unnecessary abstraction and complexity, often to solve relatively simple problems. I can't actually understand why any OS should be shipped with bugs, or why a lot of embedded products need an OS at all. The complexity is there because vendors push it and programmers enjoy it. >Many of the hardware systems I have seen are not "bug free". I don't >believe for a second that my PC has no problems in the hardware. I do >belive that they have been reduced to an acceptable level and are >largely covered up by the software bugs. But this is mainly because the >software is much more complex and changes much more rapidly adding new >bugs. If we all continued to use Windows 95 and Microsoft continued to >make patches for bug fixes, I expect we would start seeing a lot more >hardware problems and eventually see very few software problems. But >then Bill would ultimately become very poor. I bet my Dell PC would run arbitrarily complex hardware diagnostics for months without a single error. Unless, of course, the diagnostic programs had bugs. JohnArticle: 45372
On 20 Jul 2002 10:58:21 -0700, vhdlcohen@aol.com (ben cohen) wrote: >>Which of these methods do you like? >>What if design is large? what if small? Comments? >>FYI: sites of info >>http://www.cu.edu/~irm/about_irm/self_study/96_method.html >>http://www.hyperthot.com/pm_sdm.htm >>http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/watersluice.html >> >>Water_sluice methodology >>http://www-db.stanford.edu/~burback/water_sluice/sluice6.25.97/ws/sluice.gif >-------------------- >> Sounds like software methodologies are taking over logic design, so >> that we can now have FPGA's of the same quality, speed, and density >> of, say, Outlook for Windows. >> John >----------------------- ><Woohoo! >So now, when a design doesn't fit in a chip, all we have to say is >"buy a >bigger / faster FPGA" instead of worrying about fitting the design in >the >device! >Martin> ><If the design is easily fully definable, "waterfall". One of the >nice >things about this method is that: once you have defined the problem, >an >experienced designer can give a schedule that will be fairly close. >Management always likes getting a schedule that you will come close >to. >------------------------- ><If the design isn't definable, a method somewhat like "water_sluice". >Some problems just can't be defined up front. They are too complex, >or >not well enough understood. >Almost as interesting a question might be: >The software world has been dealing with larger and more complex >problems for years. As both FPGAs and ASICs get larger, the hardware >design process is able to attack more complex problems. The mistakes >made by software design teams in the past have been and are going >continue to be repeated by hardware designers in these more complex >designs. Why is there widespread hostility to learning from the >software design world? >Phil Hays> >-------------------------------------- >BEN: Agree with Phil. Also, HDL is software, with understanding of >hardware. However, I know of organizations that use the spiral method >with fpga's. The cycle is: > Rough req -> RTL (poorly documented, of course) > -> synthesis -> board test (no TB, no simulation // not needed!) > -> back to top, or to RTL. >Requirements are refined as the project goes on, and may be documented >on Note Pads/ white boards, but sometimes in WORD. >The biggest issue with the spiral method is that it's almost endless, >because there is no criteria as to when you're done. The cycle >described above has been known to continue till the last minute for >last updates/fixes. >Curious to know if others had good experiences with the spiral method. >Also, regardless of the methodology, how good is your documentation >(req, HDL, scripts)? >Waterfall method is good, but changes to requirements becomes a big >issue because you have to go back to the top of the waterfall. >--------------------------------------------------------------------------- >Ben Cohen Publisher, Trainer, Consultant (310) 721-4830 >http://www.vhdlcohen.com/ vhdlcohen@aol.com >Author of following textbooks: >* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn >0-9705394-2-8 >* Component Design by Example ", 2001 isbn 0-9705394-0-1 >* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn >0-7923-8474-1 >* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn >0-7923-8115 >------------------------------------------------------------------------------ Geez, Ben, your response to my post is an incoherent misch-mash of cuts and pastes. Like a lot of the VHDL I've seen lately. JohnArticle: 45373
"Deli Geng (David)" <deli.geng@ncl.ac.uk> wrote: > I was just wondering if SpartanII JTAG can be connected with other JTAG > device. For example, in my design, there are JTAG devices of SpartanII > FPGA, CPLD, PROM and ARM processor. Can I serially connect them together as > standard way? Theoretical yes. But i would not suggest to do so. Put only devices from one manufactor in one jtag chain, i.e. two xilinx-CPLDs, and use on the PCB more than one jtag connector for the different chains. This avoids troubles with different jtag CPU-emulators, jtag programmers, and other tools using this interface... WD --Article: 45374
Hello. I'm using Handel-C and VHDL to make a 2D filter. (DOG (Diference of Gaussians) filter indeed). I'm more interested in Handel-C. (DK-1.1) I'm doing it secuentially. For every pixel I read the pixels which are below the mask and multiply... Well. I'm using a RAM that I've defined for a Virtex-E. The filter works... but it's very slow. (12 frames per second). Any ideas for make more paralel the convolution? Multiport RAMS... ?? Thank you. -- Antonio Martínez Álvarez
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