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
Thank you for your response Ken. We have used the macro before with little difficulty. We were aware of the metastability problem with the serial input. We have the synchronization flip-flops in our design. We found the problem. It was not with the UART macro. It was with our use of the macro. We were using the rising edge of OE- to generate our read pulse. By the time OE- was synchronized and the edge detected we were 1 to 2 cycles past the rising edge of OE-. We were assured that the data would not be changing when the processor read the data. This also allowed us to read the data with zero wait states. The problem we ran into was when the buffer was empty. If the received byte was completed between when the processor read the data and the read pulse then the macro would clear Data_Present and the byte would be over written on the next received byte. This was exaggerated by the fact that we were using bit 8 (we have a 32 bit bus) of a data read to provide the Data_Present status. With one read we can get a received byte and status at the same time instead of one read for data and another read for status. This caused us to always do one more read than the data we had. If the input buffer was truly empty this did not cause a problem. The way we are fixing it is to latch the Data_Present status with our Register_Enable signal and then use this latch version to gate the read pulse. So if we read the buffer and Data_Present is not asserted on the rising edge of Register_Enable the read pulse will not be generated. The problem with this is to detect the rising edge of Register_Enable and latch Data_Present causes us to have to add 2 additional wait states for our FPGA accesses. Thanks to everyone who took the time to respond. John Ken Chapman <chapman@xilinx.com> wrote in message news:<3FB8A405.57F8D5BB@xilinx.com>... > So I confess it was me that made the macros in XAPP223 and I made a > mistake or at least an assumption. > > The serial input to the Rx is of course asynchronous to the clock and > therefore should be synchronised to the internal clock domain before it is > distributed. My macro did not do this. Unfortunately, I always use the > input flip-flops in the I/O blocks whenever possible in all designs and as > such all my testing never showed up an error. Occasional reports of errors > have always been cleared up by using a flip-flop in the serial line and of > course putting it in the IOB makes it free. Other than this issue, I have > had only happy reports by the thousand (plus requests for parity support > of course!). > > I have learnt from my mistake and have now re-implemented the UART macros > which are currently bundled with PicoBlaze (www.xilinx.com/picoblaze) > since this is where they get the most use and where the micro controller > is an ideal partner. These macros have included input synchronising > flip-flops so that they don't rely on I/O flip-flops. I guess I had to > give up an additional slice of logic to make things easier to use :-) > > Ken ChapmanArticle: 63251
Dear Colleague,
The abstract submission deadline (December 1st, 2003) for the 2004
NASA/DoD Conference on Evolvable Hardware is now approaching. The
main purpose of the one-page abstract is to provide the authors
early feedback before submitting the full paper. This will also
allow the Conference organization to start preparing the sessions
in advance.
Due to the one-page limit of the abstract, we would encourage the
authors to outline the forthcoming paper contents, explain the
main objectives of their research and summarize expected results
if that is the case.
The conference web site is at:
http://ehw.jpl.nasa.gov/events/nasaeh04/index.html
Please do not hesitate to contact the Conference Chair, Ricardo
S. Zebulum, (ricardo@brain.jpl.nasa.gov) if you have any
questions.
Abstracts should be submitted electronically to
eh-2004@cism.jpl.nasa.gov.
Hope to see you in Seattle!!!!
Ricardo Zebulum
David Gwaltney
Gregory Hornby
Didier Keymeulen
Jason Lohn
Adrian Stoica
---------------------------------------------------
2004 NASA/DoD Conference on Evolvable Hardware
June 24- 26, 2004
Seattle, Washington, USA
Hotel (TBD), Seattle, WA
Sponsored by:
National Aeronautics and Space Administration (NASA)
Department of Defense (DoD)
Supported by:
Life Detection Science and Technology, JPL (LDST, JPL)
Space Exploration Technology Program, JPL (SETP, JPL)
Information Sciences and Technology Directorate,
NASA Ames Research Center(NASA Ames)
Computing, Information and Communications Technology Program,
NASA Ames Research Center(CICT)
Advanced Computing Applications Office, NASA Marshall Space
Flight Center (MSFC)
Navy Center for Applied Research in Artificial Intelligence,
Naval Research Laboratory (NRL)
Hosted by:
Jet Propulsion Laboratory (JPL, EHW group at JPL)
The 2004 NASA/DoD Conference on Evolvable Hardware (EH-2004)
builds upon the tradition of the successful series of NASA/DoD
Workshops (the first Workshop hosted by JPL in Pasadena, 1999; the
second Workshop hosted by NASA Ames in Palo Alto, 2000; and the
third Workshop hosted by JPL in Long Beach in 2001) and
Conferences (2002 hosted by NASA Goddard in Washington, DC and
2003 hosted by AMES in Chicago ) on Evolvable Hardware. Evolvable
Hardware is an emerging field that applies evolution to automate
design and adaptation of physical reconfigurable and morphable
structures such as electronic systems, antennas, MEMS and robots.
The purpose of this conference is to bring together leading
researchers from the evolvable hardware community, representatives
of the automated design and programmable/reconfigurable hardware
communities, technology developers and end-users from the
aerospace, military and commercial sectors.
Evolvable hardware techniques enable self-reconfigurability,
adaptability and learning by programmable devices and thus have
the potential to significantly increase the functionality of
deployable hardware systems. Evolvable Hardware is expected to
have major impact on deployable systems for space systems and
defense applications that need to survive and perform at optimal
functionality during long duration in unknown, harsh and/or
changing environments. It is also expected to greatly enhance
the capability of systems that need modification, upgrade and
learning without interrupting their operation.
This year's Conference will introduce two new features: early
submission of abstracts previous to full-paper submission and the
organization of Special Sessions.
SUBMISSION OF ABSTRACTS
Prospective authors are invited to submit the electronic version
of their abstract (ie PS, PDF, MSWord) by email to
eh-2004@cism.jpl.nasa.gov . The abstract is limited to 1 page and
should be submitted in single-spaced, 10 point type on a 8.5"x11"
or equivalent paper with 1" margins on all sides. Each submission
should contain the following items: (1) title of paper, (2) author
name(s), (3) first author physical address, (4) first author e-mail
address, (5) first author phone number, (6) the text of the
abstract, and (7) references.
IMPORTANT DATES
Abstract submission deadline: December 1, 2003
Author notification abstract: December 15, 2003
Paper submission deadline: January 31, 2004
Author notification paper: March 15, 2004
Camera ready manuscript deadline: March 31, 2004
Conference: June 24-26, 2004
Article: 63252On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville <jim.granville@designtools.co.nz> wrote in <3FB95B37.5E2@designtools.co.nz>: > You could also try a Tracking ADC, rather than SAR - SAR is sensitive >to >noise, and have 'noise gain' which means large OP impulse errors can >come from small IP errors. (which is what you are seeing) > Tracking ADCs are better behaved, and would suit the faster speed / >but not analog-optimised resource in the FPGA. > > - jg Interesting, how (in priciple0 would you realize a 'tracking ADC'? This is what I do now (sort of pseudo code): // signal output from comparator is in inbit reg [3:0] position; // bit position reg [7:0] temp; // temp always .... begin if(position > 0) begin temp[position] = 1 - comparator; if(comparator == 0) da_output[7:0] = da_output[7:0] + substractor[7:0]; else da_output[7:0] = da_output[7:0] - substractor[7:0]; position = position - 1; substractor = substractor >> 1; ready = 1'b0; end else // bit 0 begin ready = 1'b1; substractor = 8'd64; da_output = 8'd128; position = 8'd7; output = temp; end end // always I left out the trigger (conversion request) and reset. I start with the r2r DA at 128 (half of 255 8 bit range), and the substractor at 64 (half of remaining range. One clock later I check the comparator output, and store the bit. If the value was bigger I go to 128 + 64 and compare again.. if smaller to 128 - 64... decrement the bit, and have teh substractor value. When bit zero comes, I copy the temp result and set ready. The real routine is bigger and does things on pos and neg edge clock. How would you write a 'tracking' one? It should not use more steps.... if possible? JanArticle: 63253
Hi Manfred, Subroto: Thank you very much for your in-depth replies. I'm happy to see that MAXIMUM_DEPTH does what I was hoping it does, because I need many RAMs at non-power-of-2 bits storage, and I'm feeling a little too lazy to write my own muxing logic. Manfred, I compiled a design that had one depth-first and one width-first RAM block, each being 1,089 x 32 bits. The depth-first used 16 M4k's as 4096x2, and the width-first used 9 M4k's as 128x32, so the functionality appears to be working for me. Perhaps certain memory configuration work properly with MAXIMUM_DEPTH, while others (ie. yours) do not? As expected the critical path was in the width-first logic, but was still 220 MHz+. I am using Quartus II 3.0 SP2. I found the release notes at http://www.altera.com/literature/rn/rn_qts.pdf. Thanks again, -- Pete Manfred Mücke <manfred.getmuecke@ridgmxof.thisat> wrote in message news:<oprysn2vdygdoir8@news.inode.at>... > Hi Peter, > > > I am wondering if I am missing out on a possible memory optimization. > yes you do. > > Quartus allocates memory by depth first, 512x8bit therefore uses two M4Ks > in 512x4 mode. If your memory width and depth is a power of two, allocation > order doesn't matter except for some speed details. But a 700x8bit memory > is much better allocated by width than by depth (because only 3 M4Ks are > needed for the first compared to 4 for the latter). (see > http://www.altera.com/support/kdb/rd03292002_9305.html for further details) > MAXIMUM_DEPTH should help you to force Quartus not to waste this addtional > memory block. > > Unfortunately it doesn't work. Not even the way Altera thinks it should > work. I had a long (and somewhat bizarre) service request the last entry > being the following one: > > -- Altera wrote > This is to let you know that a software problem request has been filed in > order to reflect this issue. I will let you know as soon the software > group gets back to me with any infomation or when a resolution is made. > -- Altera wrote much more, but [snip] > > This was written the 25th of august and the service request was closed > without further comment. I have posted an additional request asking for the > actual state of the problem request about one month ago and did not receive > any answer. Either Altera doesn't care or they don't want to state that > this is an issue at present before they are able to ship the new Quartus > 4.0 (hopefully fixing this and a lot of other things) - who knows? > If anyone in the group thinks he can help on this topic or has further > details I would be thankful to hear about it as Quartus wastes a lot of my > memory and this has to change! > > I have to say that life with Altera mySupport is very ambiguous to me. > Answers are generally quick and friendly (which is already a lot) but > generally only helpful when problems are simple. Whenever the problem gets > more complex or there is a bug thinks get very slow (or even stop). > > Regards, Manfred > > BTW: "Release notes for Service Pack 2 will be released on Friday, October > 24, 2003." (seen on > https://www.altera.com/support/software/download/service_packs/quartus/dnl- > qii30sp2.jsp the 17th november) > > > > > ======= Service Request Detail (reordered for your convenience) > Request #: 10363308 Status: Closed Date Opened (PDT): 8/19/03 9:03 AM > Date Closed (PDT): 9/4/03 6:52 PM Inquiry Type: Product Question > > Device Family: CYCLONE Device: > Title: FIFO implementation size > > Description: I have created a 1300word by 8bit FIFO (sfifo). The > implementation of this needs 16384 memory bits. Why? > > The FIFO-size should result in about 1300x8=10400 memory bits. As the > blocksize of the embedded ram in Cyclone is 4096bits which can be organized > 512x8 I expect Quartus to use three M4K's resulting in 4096*3=12288bits. > Obviously it uses a fourth block, why? > > Regards, Manfred > ------ 8/19/03 3:17 PM > To Customer > Hello Manfred, > > This is to let you know that I am currently looking into this. I will let > you know as soon as I am able to verify the problem as you have described > and come into a resolution. > > ------ 8/19/03 4:20 PM > To Customer > Hello Manfred, > > Since 1300 is larger than 1k, it'll use 2kx2 mode for best performance. To > get the x8 mode you'll need 4 M4Ks. Click custom on (page 6 out of 8 of > the megawizard), then you get an option to set Maximum depth option and if > you set 512 then it'll use that mode and should only need 3 M4Ks. > > For more information on this, you may refer to the following link: > > http://www.altera.com/support/kdb/rd03292002_9305.html > > ------ 8/20/03 12:36 AM > From Customer > Hello Marlon, > > thanks for your quick and helpful reply. Now the behaviour of Quartus is > clear to me. > Unfortunately setting the parameter max. block depth to 512 in the > Megawizard Plug-In Manager as you proposed does not result in a smaller > memory consumption. I have attached the packed project for your > convenience. > Setting this parameter adds the following line in the scfifo instantiation > code: maximum_depth => 512, > however this parameter is not described in the Quartus II help page for the > scfifo-Megafunction. Why? > > Regards, Manfred > > ------ 8/20/03 9:47 AM > To Customer > Hello Manfred, > > The MAXIMUM_DEPTH parameter is an internal parameter so there won't be any > information on this in the Quartus II Help or Megawizard. > > ------ 8/20/03 11:26 PM > From Customer > Hello Marlon, > > again: Unfortunately setting the parameter max. block depth to 512 in the > Megawizard Plug-In Manager as you proposed does NOT result in a smaller > memory consumption. Why? Please check with the attached project file. > > Regards, Manfred > ------ 8/21/03 5:08 PM > To Customer > Hello Manfred, > > Sorry for the inconvenience, but actually, in order to get the x8 mode > you'll need 4 M4Ks. > > ------ 8/21/03 11:49 PM > From Customer > Hello Marlon, > > could you please specify why it is not possible to implement a 1300x8 FIFO > in 3 M4K Blocks as this information is the opposite of both your first > advice and the mentioned support database page > (http://www.altera.com/support/kdb/rd03292002_9305.html). > What exactly is the parameter maximal block depth for then? > > Regards, Manfred > > ------ 8/25/03 6:50 PM > To Customer > Hello Manfred, > > This is to let you know that a software problem request has been filed in > order to reflect this issue. I will let you know as soon the software > group gets back to me with any infomation or when a resolution is made.Article: 63254
1. No problem. I'm not a buyer, so I don't know where they came from. 3. Don't know, but if you hook up the CF pin to PROG, then you can tell Impact to make the FPGA load from the PROM after the programming/verification is complete. You check a box in the "Program..." dialog. Barry "Robert Sefton" <rsefton@abc.net> wrote in message news:bpc3nl$1nibph$1@ID-212988.news.uni-berlin.de... > I need to configure an XC2V6000 from flash. Planning to use six XCF04S > PROMs, but I have a few questions. > > 1. Anyone having problems buying these PROMs? Avnet had some in stock > last week, but today they had none. What kind of lead times should I > expect? > 2. Does the Xilinx Impact software fully support in-system JTAG > programming of a chain of serial PROMs? Is ISE 5.2i sp3 the required > version? > 3. Does the software also support direct JTAG downloading to the FPGA if > it sits at the end of the same JTAG chain with the PROMs in it? > > I'm a little wary of committing to this path and losing time due to tool > problems or inability to get parts. > > Thanks, > > Robert > > >Article: 63255
OK, the DCM input clock goes away, and I understand the LOCKED signal is not valid. After the input clock comes back, can you rely on the LOCKED signal to indicate that a DCM reset pulse is needed? And ditto that question for the STATUS(2) signal when you are using the CLKFX output? I'm trying to avoid creating an extra independent clock (with some little oscillator) that would be used to clock a state machine to generate the DCM reset pulse when STATUS(1) indicates loss of input clock. So I thought to use the input clock itself for the state machine, and test the LOCKED signal to decide about reset. After all, there's no point in resetting the DCM until after its input clock has returned. I hoped the Xilinx website might have an example circuit to handle DCM reset, but I couldn't find anything. Barry BrownArticle: 63256
Barry, Within a few thousands of clocks after the clock has returned (depending on the settings of the jitter filters), the DLL will either be locked, or LOCK will go low (indicating that the DLL has run off the ends of the delay lines due to the interruption), or CLKIN_STOPPED will still be high indicating the clock really did not come back as expected. If the CLKFX output is also being used, and interruption at all will lead to the CLKFX_STOPPED bit asserting high. Easier to just use LOCKED going low after it has already gone high, OR CLKIN_STOPPED going high OR CLKFX_STOPPED going high as your trigger to reset. Hope this helps in your little state machine design. Austin Barry Brown wrote: > OK, the DCM input clock goes away, and I understand the LOCKED signal is not > valid. After the input clock comes back, can you rely on the LOCKED signal > to indicate that a DCM reset pulse is needed? > > And ditto that question for the STATUS(2) signal when you are using the > CLKFX output? > > I'm trying to avoid creating an extra independent clock (with some little > oscillator) that would be used to clock a state machine to generate the DCM > reset pulse when STATUS(1) indicates loss of input clock. So I thought to > use the input clock itself for the state machine, and test the LOCKED signal > to decide about reset. After all, there's no point in resetting the DCM > until after its input clock has returned. > > I hoped the Xilinx website might have an example circuit to handle DCM > reset, but I couldn't find anything. > > Barry BrownArticle: 63257
I have transported a design from Altera APEX to STRATIX. The previous
design´s Lookup Tables (LUTs) that were in ¨lpm_rom¨ modules have been
transported to ¨altsynchram¨ modules. Now QuartusII3.0 sends an error
message:
> Error: Groups cannot be assigned to nodes
When I locate the message´s origin, it points to the following file:
/appl/quartusII3.0/libraries/megafunctions/altsyncram.tdf
Here on the line #1501:
ram_block[0][i].portaaddr[] = address_a[];
The design itself was already simulated by Cadence(TM) on behavioral
level, with all lpm-s inside, without any error. The Synthesis tool
Synplify did not give error message either. Perhaps a bug in Quartus?
Any idea?
Thanks,
Janos Ero
CERN Div. EP
Article: 63258I am attempting to use this XILINX software with this board and chip. In order to test it, I create a simple design that incorporates an AND2 gate, two input buffers, and one output buffer all of which (the input and output buffers) are connected to IPADs. The IPADs are assigned pin numbers on the Schematic with the parameters LOC=Pxx, where xx is 27, 28, and 69. These correspond to SW1, SW2, and LD1. The design implements correctly, and the bit file is generated successfully. When I transfer the design to the board, NOTHING HAPPENS! This is a very frustrating problem, and I cannot determine the solution. If I can't get this simple design to work, then the boards are practically worthless. I installed the two recommended updates for the F1.5 software, ftp://ftp.xilinx.com/pub/swhelp/M1.5_updates/15_service_pack1_nt.zip and ftp://ftp.xilinx.com/pub/swhelp/M1.5_updates/15_sp1_ftp2_nt.zip. I don't know what else I am supposed to upgrade the software with to perhaps fix this problem. I have already tried other miscellaneous patches posted on the site, but none allows this simple design to work. Has anyone else encountered this problem with XILINX Foundation F1.5, and the Digilab XLA with the XCS10PC84 chip? Thank you. --Article: 63259
"Jan Panteltje" <pNaonStpealmtje@yahoo.com> wrote in message news:1069193901.982088@evisp-news-01.ops.asmr-01.energis-idc.net... > On a sunny day (Tue, 18 Nov 2003 12:35:19 +1300) it happened Jim Granville > <jim.granville@designtools.co.nz> wrote in <3FB95B37.5E2@designtools.co.nz>: > > > You could also try a Tracking ADC, rather than SAR - SAR is sensitive > >to > >noise, and have 'noise gain' which means large OP impulse errors can > >come from small IP errors. (which is what you are seeing) > > Tracking ADCs are better behaved, and would suit the faster speed / > >but not analog-optimised resource in the FPGA. > > > > - jg > Interesting, how (in priciple0 would you realize a 'tracking ADC'? > I left out the trigger (conversion request) and reset. > I start with the r2r DA at 128 (half of 255 8 bit range), > and the substractor at 64 (half of remaining range. > One clock later I check the comparator output, and store > the bit. > If the value was bigger I go to 128 + 64 and compare again.. > if smaller to 128 - 64... This is SAR, as you mentioned. Tracking ADCs have a saturating Up/Dn counter, and INC/DEC based on the comparitor result. They have a finite slew rate, but the counting clock speed can be higher than the read-out rate. Their advantage is the inherent low pass/noise filtering nature of the feedback so in a 'less than ideal' environment like a FPGA Comparitor/DAC, they could help. They can be made adaptive, so the INC/DEC size increases if many INC/DECs occur in the same direction (as in ADPCM), to improve the step response. -jgArticle: 63260
I've got information that the CPLD uses 50k bus-holding feature. I've used 12k resistor in my reseting circuit instead of 130k and this solved the problem. However, I turrend bus keeping off in WebPack->fitter option. It is obusfucating. 3.3v*130/(130+50) = 2.35v I was getting when my 130k was pulling reset down and CPLD's keeper feature pulled it up with 50k. One thing I still do not understand is why 3.3v CPLD pulls up input to 2.4v.Article: 63261
Hi,
Does anyone out there in usenet-land know of tools to let you design
Printed Circuit Boards with VHDL? I'm ready to switch from schematic entry,
I want portability! (And all the other good reasons I switched from
schematic entry for my FPGA designs) Anyone use a PCB layout tool that
accepts EDIF files? I see there are translator tools. Anyone ready to share
their experiences, pitfalls et cetera?
thanks for reading, Syms.
Article: 63262On 18 Nov 2003 07:53:10 -0800, petersommerfeld@hotmail.com (Peter Sommerfeld) wrote: >Oops, looking through the thread I see you want a Verilog sim. >Symphony is only VHDL. Symphony is a good example though. A one-year node-locked license of the "Standard" version costs US$199. There doesn't seem to be any comparable Verilog simulator in that price range. Regards, Allan.Article: 63263
On Tue, 18 Nov 2003 22:02:59 +0200, "Valentin Tihomirov" <valentin@abelectron.com> wrote: >Downlad a trial from Altec. This prevents you from ascking stupd questions. Was that directed at me or Rick? Which questions were "stupd" ? Allan.Article: 63264
Dan - I assume you're talking about the Xilinx core from Modelware? I worked on a project last year where we used the core in a Virtex2 on a daughtercard to interface with and test the ASIC we built. I worked on the ASIC SPI-4 interface and designed the boards, but I did not actually do the SPI-4 FPGA work. I can't vouch for the power number, but it sounds reasonable. It's very hard to isolate in a system beacause you wrap a lot of logic around the core inside the FPGA. All in all the core worked as advertised with the possible exception of dynamic alignment. It's been out there for quite a while now. I personally wouldn't hesitate to use it. I forwarded your post to the engineer who did the FPGA work and his edited response is below. The BGA connector he refers to is the mezzanine connector between the ASIC and the daughtercard. Good luck, Robert "We might have tried Dynamic Alignment once, but that was several SPI-4 core revisions ago. Otherwise, we've stuck with static alignment. I haven't done any power measurements. Xilinx has a spreadsheet that can calculate power based on the actual design file (ncd). But I bet this is how they came up with the 2Watt spec. I am currently running the SPI cores (rx and tx) at 296MHz, which is 592MBit double data rate. We ran previously at 320MHz (640Mbit DDR), but we were getting occasional SPI-4 DIP4 errors. Even at the 296MHz rate, we've had to turn off the training patterns that we send to the ASIC to get rid of SPI-4 framing errors. Sounds like it has difficulty distinguishing between data frames and training patterns sometimes. Adding dynamic alignment would not fix this, because that only applies to the rx core. I wonder if going through the BGA connector is aggravating the problem. We haven't spent much time debugging this issue, because the 296MHz clock rate is sufficient for now." "Dan Schaffer" <dan-schaffer@comcast.net> wrote in message news:nwrub.236601$Tr4.696017@attbi_s03... > Has Anyone used the SPI 4.2 Core? > How well is it implemented? > Any idea of the power consumption? I'm wondering if the 2W specs on the web > site are valid. > > Thanks, > Dan > >Article: 63265
Valentin Tihomirov wrote: > > I've got information that the CPLD uses 50k bus-holding feature. I've used > 12k resistor in my reseting circuit instead of 130k and this solved the > problem. However, I turrend bus keeping off in WebPack->fitter option. It is > obusfucating. 3.3v*130/(130+50) = 2.35v I was getting when my 130k was > pulling reset down and CPLD's keeper feature pulled it up with 50k. > One thing I still do not understand is why 3.3v CPLD pulls up input to 2.4v. Pinkeepers are not true resistors, but are weak N FETS (reason of smallest die area ) They seem to make the pinkeeps using N+N FETS, rather than N+PFETS,and the pullup is the N Source follower, so you get a G-S drop, or appx 0.9V of threshold. Put your meter from Pin-3.3V, and it will read 0.0V, Put it from Pin-GND, and it reads 2.4V. Atmel CPLD data has curves of the I-V for pinkeeps that makes this clearer. -jgArticle: 63266
On Tue, 18 Nov 2003 17:49:24 -0800, "Symon" <symon_brewer@hotmail.com> wrote: >Hi, > Does anyone out there in usenet-land know of tools to let you design >Printed Circuit Boards with VHDL? I'm ready to switch from schematic entry, >I want portability! (And all the other good reasons I switched from >schematic entry for my FPGA designs) Anyone use a PCB layout tool that >accepts EDIF files? I see there are translator tools. Anyone ready to share >their experiences, pitfalls et cetera? Features like pin swapping, gate swapping and cross probing will only work with a tightly integrated pcb and "source" toolset. I suspect you would lose this with an HDL front end, although they do seem possible in theory. Frankly, the thought of designing a switchmode power supply using an HDL scares me. Designing a microstrip filter using an HDL seems nigh on impossible. (Hint: both these applications require careful layout, which is something that can be more easily expressed with a graphical entry tool.) Regards, Allan.Article: 63267
I can't agree with you on this. I fail to see how what you wrote could be offensive, nor do I see how anyone who's in the FPGA world could conclude or extrapolate that something is being said about the quality of Xilinx's app notes. But, then again, I'm biased, I use their chips and love them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message news:bpcpim$5v3$1$8300dec7@news.demon.co.uk... > I owe some folk an apology. > > "Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in > message news:bovsnb$6o5$1$830fa7b3@news.demon.co.uk... > > > Don't be silly; if it's in a Xilinx appnote, it's _ipso facto_ > > conventional :-) > > When I wrote that, my intent was only to poke mild fun at > the fact that Xilinx appnotes are such a pervasive part > of the FPGA design culture that they almost *define* what's > conventional. But I didn't write it very well, and it was > misunderstood as a slur on the quality of Xilinx material. > That would have been quite absurd and I unreservedly > apologise for any offence. > > Xilinx apps people have done us all a great service over > the years by sharing a huge variety of tips and techniques > (some conventional, some highly creative). I've had many > occasions to be grateful for that. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK > Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: http://www.doulos.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. > > >Article: 63268
"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:h2klrvs2rsdl9r2s3co2slnmp0kh7kvl66@4ax.com... > On Tue, 18 Nov 2003 22:02:59 +0200, "Valentin Tihomirov" > <valentin@abelectron.com> wrote: > > >Downlad a trial from Altec. This prevents you from ascking stupd questions. > > Was that directed at me or Rick? Which questions were "stupd" ? > > Allan. Hi Allan, Your thread is quite informative. Don't pay attention to such rough letters. Valeri.Article: 63269
Hi Allan, I tend to agree with your opinions. I just wanted to add that PCB layout tools that generate VHDL/Verilog netlists are very useful for system level simulation. Obviously this is not the information the original post was attempting to obtain but I wanted to throw it out there for others to contemplate. Matt "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:o0plrvk7kvd3mm2evhd0fr6nd1kdu26d3e@4ax.com... > On Tue, 18 Nov 2003 17:49:24 -0800, "Symon" <symon_brewer@hotmail.com> > wrote: > > >Hi, > > Does anyone out there in usenet-land know of tools to let you design > >Printed Circuit Boards with VHDL? I'm ready to switch from schematic entry, > >I want portability! (And all the other good reasons I switched from > >schematic entry for my FPGA designs) Anyone use a PCB layout tool that > >accepts EDIF files? I see there are translator tools. Anyone ready to share > >their experiences, pitfalls et cetera? > > Features like pin swapping, gate swapping and cross probing will only > work with a tightly integrated pcb and "source" toolset. > > I suspect you would lose this with an HDL front end, although they do > seem possible in theory. > > > Frankly, the thought of designing a switchmode power supply using an > HDL scares me. Designing a microstrip filter using an HDL seems nigh > on impossible. > (Hint: both these applications require careful layout, which is > something that can be more easily expressed with a graphical entry > tool.) > > Regards, > Allan.Article: 63270
Where can i get the information about DC-FPGA? I've searched Synopsys website, but got nothing :(Article: 63271
If you are going to play with the seed, you need to try several settings before you can say it won't work. I once worked on a real b--ch of a design and my coworker set up a script that would run multiple passes overnight. That was the only way we ever got the thing working. he also had to write AWK scripts to parse the timing results since this was MaxPlus2 and the thing pretty well sucked for timing analysis. I believe Quartus is much better now. But it left a bad taste in my mouth for Altera software. I'll get over it some day... Kumaran wrote: > > Hi Manfred, > Thanks for your response. I am using the dedicated clock pin 79. I had > a look at other threads for optimizing the speed. Some one mentioned > that by increasing the seed in the fitter setting might increase the > speed, but, they also mentioned that there will only be a slight > improvement, and I saw a slight increase in the speed(not good > enough). Any other suggestions? Thanks for your time. > > Thanks, > Kumaran > > "Manfred Balik" <e8825130@stud4.tuwien.ac.at> wrote in message news:<3fb9d94f$0$18702$3b214f66@tunews.univie.ac.at>... > > It looks like you didn't use the internal Clock-Network. > > Use the dedicated Clock Pins 79 or 183 (and maybe the internal PLL) to have > > the same delays of clock signal to each gate. > > Manfred > > > > > > "Kumaran" <kumaran@trlabs.ca> schrieb im Newsbeitrag > > news:40f2d3e9.0311171247.ab73d04@posting.google.com... > > > Hi all, > > > I am targeting my design on Acex EP1K100QC208-3 FPGA. I did most of my > > > development using Leonardo Spectrum synthesizer(2002) and Max +2. My > > > license for leonardo expired, and I decided to use Quartus II(v3.0). > > > When I compile using Quartus, Iam getting a negative slack time for > > > one of my clock. when I compiled the same FPGA code using LS and Max > > > +2, I did not have any timing issues . In the compiler settings, I > > > have enabled the "optimize i/o cell register placement for timing" > > > option. I also tried different synthesis tool in quartus (FPGA > > > express, LS,..) but I could not get the timing right. Can anyone help > > > me? > > > > > > Thanks, > > > > > > Kumaran -- 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: 63272
There are plenty of us who would like to use a nice low cost tool such as this, if it works well. Please keep us informed of any issues you find. Peter Sommerfeld wrote: > > Hi Allan, > > Have you looked at Symphony EDA? It is 10% of Aldec's cost. I use > Aldec, but Symphony looks promising to me (I started using it a week > ago). It's interface is very similar, but it does not have all the > bells and whistles of Active-HDL. > > -- Pete > > Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<g62jrvopslpsj5tpdfmi978imnp7cuo9s2@4ax.com>... > > On Mon, 17 Nov 2003 19:27:22 -0500, rickman <spamgoeshere4@yahoo.com> > > wrote: > > > > >Have you looked at any of the open source tools? Is that what Icarus > > >is? I am not familiar with them, but I know they exist. > > > > Yes, I am looking at commercial software because I am currently using > > an open source tool (Icarus). > > > > My experience is that "open source" isn't necessarily the same as > > "good quality" when applied to EDA tools - both the developer and the > > user communities are just too small to achieve quality comparable with > > commercial EDA tools (or Linux, for that matter). > > > > I wish that someone could prove me wrong! > > > > Regards, > > Allan. -- 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: 63273
hi all, i have no of D flip flops cascaded now there are two ways clock can be routed. 1) in the direction of the data flow. 2) opposite to the direction of the data flow. which of the above is good?? thanks in advance rgds, praveenArticle: 63274
Hello! Is anyone of you familiar with the Xilinx Application Note XAPP134? (downloadable at http://direct.xilinx.com/bvdocs/appnotes/xapp134.pdf , ftp://ftp.xilinx.com/pub/applications/xapp/xapp134_vhdl.zip) My questions are: * From the system, you can control the SDRAM with commands that are defined through data_addr_n, we_rn and AD[29:28]. When I set one command, does it have to be set back to zero afterwards and when? E.g. when I write, I first set the addr_wr command and the address, then the data_wr command and the data, but afterwards, do I have to set everything (including the AD-bus) back to zero? (because, also zeros stand for a command). * I am wondering what I have to do at the very beginning: At first, I put a reset, and it takes some time until I can perform any action. Then I precharge and load the controller mode register (this has to be done before anything else can be done, right?) But then....? Do I have to load the SDRAM mode register before I can read/write/auto refresh/... * And did I understand right, that I still have to do the refresh by hand, so every 64ms? By issueing the command AUTO REFRESH? Or does the controller already do this for me? * But now, finally the last question: In the future, I need a 16-bit-wide-data-bus-design for a 32mb module instead of the 32-bit-design that is given here. The data destination should then be masked by the DQMs. How can I easily convert this? Thank you VERY MUCH! :-) Simone Winkler
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