Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Hi, Be gentle, please! I've started reading "The Student's Guide to VHDL" and have puchased a CoolRunner II Development Kit from Xilinx (very nice and reasonably priced) - the kit gave me all the s/w I think I'll need for a while, though the manual is rubbish, hence the book. Book seems very good - accessible and easy to use - about half way through now - I program professionally anyway, and have an EE background, so its not too tough (quite fun actually...). Now, I know very little about this subject, but I like making clocks... Is a digital alarm clock (7 seg LEDs or other display technology) a reasonable project to start out with? Normally I'd have done this with a PIC or AVR, but it occurred to me that using a CPLD would be... well... different.... But is it sensible? I would appreciate any comments on this approach, preferably helpful ;-) BTW. This is *not* a student project - my student days were about 25 years ago, hence my having "fun" learning different stuff... Many thanks MikeArticle: 65801
I heard rumours XILINX will announce Virtex-3 later this year, but a VIRTEX-3 PRO is not planned. Will FPGAs with integrated Processors share the destiny of the X6200 series ?Article: 65802
Thomas Womack wrote: > In article <c00e21$77m1@cliff.xsj.xilinx.com>, > Austin Lesea <austin@xilinx.com> wrote: > >>Steve, >> >>Quite frankly, I am amazed at how folks think about this. You have >>obviously never thought about that computer on your desk, and how it can >>be sold for $499! Or even your car, just go price the parts >>individually some time. > > > I've often priced the parts for building a computer, and they add up > to something within 15% of the price of buying the computer from Dell. > Moreover, the price for Intel CPUs in the shop is the same to within > about 15% as the price stated for thousand-unit quantities in their > press releases. > > I believe FPGAs are comparably complicated to Intel CPUs, and I don't > think there's as much as an order of magnitude difference in production > quantity. > > Is the market volatility for FPGAs that much greater? An Intel cpu doesn't cost 4.70$ on whatever quantity. And the margin on intel cpus is sufficient on all levels. > > >>If you have any optimism about your business at all, it would be >>best to enter into a agreement and let the disti (and us) know where >>you think you are going, and how many you will need. > > > I can understand that attitude for people buying ten thousand chips; > but where do you expect people to get the experience with FPGAs that > they have with microprocessors, when state-of-the-art FPGAs are two > orders of magnitude more expensive and an order of magnitude less > convenient to acquire? The cost is at the FPGA representative, distributing the stuff. They get the questions asked. > > >>Because they are a fair representation of the costs associated with >>small numbers of parts ordered through distribution to allow for a >>profitable business by the distis and reps. > > > But, again, why doesn't the same argument apply to CPUs, for which > there are half a dozen distributors in most towns, fairly happily > distributing the things for a couple of percent profit margin. You say it. There are half a dozend shop selling cpus per town. You go there, get a cpu, no questions asked, no questions answered. They wouldn't be able to answer anyway. There may be one FPGA representaive per state. And you ask a lot of questions. Not because you're more stupid than a cpu buyer, but because placing a cpu and applying an FPGA are completely different. ReneArticle: 65803
I am interested in using a floating-point unit on a Virtex II Pro system as software emulation is very slow. Does Xilinx have any plans to develop such a unit? I am thinking about trying to implement a simple FPU in the FPGA to speed things up, but I am not sure as to the best way to connect it to the PPC core. I would like this core to be accessible to any C/Linux program running on the PowerPC unit if possible. According to the datasheet it is possible to trap floating-point operations and handle them that way, but I'm concerned that the overhead may negate any gains of hardware implementation. Any advice?Article: 65804
Hello, I'm getting the following warning when implementing my design using Xilinx Alliance M1.3 tools: WARNING:NetListWriters:117 - Signal S_CTRL_PC_CONTROL(2) not found for signal bus S_CTRL_PC_CONTROL( 3 downto 1 ) on block CPU. WARNING:NetListWriters:107 - Signal bus S_CTRL_PC_CONTROL( 3 downto 1 ) on block CPU is not reconstructed. My gate level simulation is not working and I suspect these types of warnings are the culprits (I get several of these warnings for different signals). Does any one have any hints? Thanks, PeterArticle: 65805
The table is now part of the site, see http://www.fpga4fun.com/designsoftware.htmlArticle: 65806
Manfred, be assured that Xilinx will announce a new Virtex family this year, and be also assured that the family will include MGTs and PPC microprocessors. Don't worry about the exact family names, that's a marketing issue. The best stuff is still to come ! Peter Alfke =================== Manfred Kraus wrote: > > I heard rumours XILINX will announce Virtex-3 later this year, > but a VIRTEX-3 PRO is not planned. > Will FPGAs with integrated Processors share the destiny of the X6200 series > ?Article: 65807
Matt, Yes (we have plans, and further...). Contact your FAE. Austin Matt Parks wrote: > I am interested in using a floating-point unit on a Virtex II Pro system as > software emulation is very slow. Does Xilinx have any plans to develop such > a unit? I am thinking about trying to implement a simple FPU in the FPGA to > speed things up, but I am not sure as to the best way to connect it to the > PPC core. I would like this core to be accessible to any C/Linux program > running on the PowerPC unit if possible. According to the datasheet it is > possible to trap floating-point operations and handle them that way, but I'm > concerned that the overhead may negate any gains of hardware implementation. > Any advice? > >Article: 65808
Austin Lesea wrote: > You learned the right stuff. Still applies. If a disti orders 100 > parts (and they do) we have to process just that many parts for that one > order. Buying XC2V6000 at nuhorizons I get a 600$ discount going from 24 pieces to 100 pieces. You really think that there are than 14.000$ distribution cost for distributing 24 FPGAs? (24 times 600$) > Disti's don't want to stock anything anymore, so that makes > costs go. > > Imagine Xilinx' dilemma: what do we build? and when do we build it? > If we have an order for 100K parts spread out over a year, everything is > trivial, and less costly. But if we have seemingly random orders > popping in all of the time, we have to build ahead (risk) and sometimes > scrap parts that are not moving. [...] > > We can't seem to convince disti's to work for free, however, so they > charge what they feel they need to in order to make a profit. Disti's > also have 200+ FAEs of their own on their payrolls to support their > products, as well as order entry systems, stocking(?), unsold inventory, > stocking losses, uncollectable accounts (deadbeats), etc. Austin: Some of these are self made problems. In germany for example Avnet and Insight are the only Xilinx distributors for your FPGAs. These are huge distributors that have an organization tailored for large customers with large orders. (My last insight order involved about a dozen emails from me and three letters from Insight. I can see that that is costly, but it is unecessary) Both are reluctant to even talk to me about 2.000€ orders and I have prove that they outright lied to me about stock at least twice. Why don't you get yourself a small distributor in addition to these? One without hundreds of FAEs. Without trade fair appearances that cost hundreds of thousands of dollars. One that is happy to stock a number of standard parts and make a 30% profit with them? Kolja SulimmaArticle: 65809
Austin wrote: > Quite frankly, I am amazed at how folks think about this. You have > obviously never thought about that computer on your desk, and how it can > be sold for $499! Or even your car, just go price the parts > individually some time. Thomas Womack <twomack@chiark.greenend.org.uk> writes: > I've often priced the parts for building a computer, and they add up > to something within 15% of the price of buying the computer from Dell. You may have priced the subassemblies such as the motherboard, CD-ROM drive, etc. Try pricing the actual components (chips, passives, etc.) in small quantity. You'll be lucky if you can get a total BOM cost less than five times Dell's price. The car example is even better. If you buy all the parts from Toyota (or any of the manufacturers) to assemble a new car, you'll pay ten times the price of the car. > Moreover, the price for Intel CPUs in the shop is the same to within > about 15% as the price stated for thousand-unit quantities in their > press releases. This is because the distribution chain is willing to accept very low margins on the CPUs, because they can move such high volume. Try buying a north bridge chip and see how that experience compares.Article: 65810
Austin Lesea wrote: > We can't seem to convince disti's to work for free So why don't you sell off your web pages for people who don't want FAE support and the rest?Article: 65811
Hi, This is probably not your issue. Let's say your S_CTRL_PC_CONTROL bus has one of the bus signals tied to a constant. These get optimized away in the physical implementation. When you write out a simulation netlist afterwards, the netlist writer tool is letting you know, "Hey, I can't find this net anymore..." and that it cannot reconstruct the complete bus. However, it should still simulate correctly. Eric Peter Horst wrote: > > Hello, > > I'm getting the following warning when implementing my design using > Xilinx Alliance M1.3 tools: > > WARNING:NetListWriters:117 - Signal S_CTRL_PC_CONTROL(2) not found for > signal > bus S_CTRL_PC_CONTROL( 3 downto 1 ) on block CPU. > WARNING:NetListWriters:107 - Signal bus S_CTRL_PC_CONTROL( 3 downto 1 > ) on > block CPU is not reconstructed. > > My gate level simulation is not working and I suspect these types of > warnings are the culprits (I get several of these warnings for > different signals). Does any one have any hints? > > Thanks, > > PeterArticle: 65812
Kolja, Now you bring up another interesting factor: are we interested in small business, or big business, or both? Are our distributors interested in small business, big business, or both? I think everyone would say they are interested in ALL business, but... Not so much different than when you go to a store, buy one can of Coca-Cola, and then ask for a discount, and help with your other bags as you leave the store.....not to mention you would like it a little colder, please. Do you go to the store often? Is your business worth it? Are they losing money for such a small service? Serious questions. Small business is not afraid to innovate, and sometimes wildly suceeds(or at least they do here in Silicon Valley on occasion). I remember a paper by a certain tiny company on networking in San Francisco in 1988 that was laughed at by the attendees of the conference (it was Cisco -- who is laughing now?). AustinArticle: 65813
"CyberFunk" <htchang@comcast.net> wrote in message news:<15HUb.189826$nt4.804855@attbi_s51>... > Thanks for the reply. > But the XY coordinate printed out by partgen doesn't match with > EPIC's RPM grid shown when I click the pad. Is it partgen software bug? > Is there anyone representing Xilinx can answer this question? > Thanks. The coordinate in column six of the partgen pkg file is the location of the nearest slice site in terms of the slice coordinate system. This functionality was probably spec'd before the RPM Grid was available and there was no coordinate available to describe an IOB. It also likely predates the support of IOBs in RPMs. I'll log an enhancement for partgen asking that an RPM Grid coordinate be used instead. I can recommend a semi-automatic solution using FPGA Editor. As you've noted, the RPM Grid coordinate is printed when an IOB site is selected. This information is written to a file named design_name_fpga_editor.out which later becomes design_name_fpga_editor.log after the editing session is finished. A perl script could be written to extract the site name and corresponding RPM Grid coordinate from this file. I was hoping that an FPGA Editor script could be used to automate the selects, but unfortunately the coordinate only gets printed when there is a manual select. BTW, keep in mind that the placer can not currently auto-place RPMs containing IOBs. You'll need to locate the RPMs with an RLOC_ORIGIN constraint. Regards, Bret > > "John Williams" <jwilliams@itee.uq.edu.au> wrote in message > news:40222fe9$0$10532$61ce578d@news.syd.swiftdsl.com.au... > > CyberFunk wrote: > > > Hi there, > > > Is there any way to convert PAD name (package pin name) to > > > (X,Y) RPM coordinate used in Xilinx FPGA editor. > > > TIA > > > > Try running "partgen -v partname" > > > > where partname is, e.g. cx2v1000-fg456-4 > > > > then open up the partname.pkg file. > > For example, from xc2v1000-fg456-4.pkg: (watch the wrap) > > > > pin PAD1 B4 0 IO_L01N_0 X1Y79 0S > > 0 > > pin PAD2 A4 0 IO_L01P_0 X1Y79 0M > > 0 > > pin PAD3 C4 0 IO_L02N_0 X1Y79 1S > > 0 > > > > Thus pin B4 is located at slice X1Y79, and so on.. > > > > You could look at the part in FPGA editor to confirm. > > > > Regards, > > > > JohnArticle: 65814
It looks fine except for functional/timing simulation. Xilinx has MTI starter which is VHDL or Verilog, but only 500 lines of code. Altera has their own gate level simulator. Both have issues, but it is unfair to just say NO for Xilinx and YES for Altera. Peter Alfke, Xilinx =========================== Jean Nicolle wrote: > > The table is now part of the site, see > http://www.fpga4fun.com/designsoftware.htmlArticle: 65815
Mike Deblis wrote: > Hi, > > Be gentle, please! I've started reading "The Student's Guide to VHDL" and > have puchased a CoolRunner II Development Kit from Xilinx (very nice and > reasonably priced) - the kit gave me all the s/w I think I'll need for a > while, though the manual is rubbish, hence the book. Book seems very good - > accessible and easy to use - about half way through now - I program > professionally anyway, and have an EE background, so its not too tough > (quite fun actually...). > > Now, I know very little about this subject, but I like making clocks... Is a > digital alarm clock (7 seg LEDs or other display technology) a reasonable > project to start out with? Normally I'd have done this with a PIC or AVR, > but it occurred to me that using a CPLD would be... well... different.... > > But is it sensible? I would appreciate any comments on this approach, > preferably helpful ;-) Yup, a CPLD should be able to handle this real easily. Even a 6-digit clock should only need about 40 FFs and a few dozens of gates. JonArticle: 65816
Steve wrote: > I've been looking for historical prices of FPGAs to try and get an > idea of what I might expect to get for a given price for small > quantities and came across this post: > > http://tinyurl.com/36blb > > which has a price table for small quantities (<=25) for January 2000: > > Spartan > XCS05 3PC84C 10.00 > XCS10 3PC84C 18.10 > XCS20 3PQ208C 40.40 > XCS30 3PQ208C 45.35 > XCS40 3PQ208C 49.15 > > Virtex > XCV50 4PQ240C 55.40 > XCV100 4PQ240C 104.00 > XCV150 4PQ240C 128.00 > XCV200 4PQ240C 157.00 > XCV300 4PQ240C 244.00 > XCV400 4HQ240C 344.00 > XCV600 4HQ240C 581.00 > XCV800 4HQ240C 860.00 > I just got some XCS30-3TQ144C for $24, although there was another broker who assured me that $67 was a really great price for them. (Yeah, a really great price for HIM!) I also got a quote a while ago for these parts from a Chinese supplier that was so low, they had to be either bootlegged or Chinese copies of the Xilinx part. I decided not to buy from that supplier, as they wanted a bank wire transfer in advance, too. > > Also, what does happen to FPGA prices over time? Do they just reach a > final value and they never get any cheaper? No, they get more expensive! I have found that the prices of 5 V Spartan chips is going UP, and maybe going up wildly! (Like the guy who though I'd pop for the $67 chips.) JonArticle: 65817
reg [7:0] TYPEFIL_REG=uno; You can initialize when targeting to synthesis (only for verification). Use reset instead. if(posedge clock or negedge reset_n) begin if(~reset_n) .... else .. Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061216.7206d4cf@posting.google.com>... > filippdavid@yahoo.com (filippo) wrote in message news:<18add487.0402060204.340e7b39@posting.google.com>... > > I' m having great troubles making a small project on FPGA in Verilog. > > I have to do it for an exam at university, it shoul be simple but it's > > becoming hell. > > > > problem: > > > > all simulations with modelsim are good, but it just doesn' t work on > > the real FPGA and i don't know where to find a solution (or where is > > the real problem). > > Did you perform both pre- and post-route simulations? What does your > test bench actually do? Is it a real bus-functional model of your > microcontroller? Or are you just setting and clearing signals in some > arbitrary fashion? I would imagine that this is the root of your > problem -- your simulation is bogus. As they say: garbage in, garbage > out? > > What about your timing constraints? > > > of the 10+ modules one seems to be the most troublesome, our > > IO_control, here is the code ,please help. > > > > --------------------------------------------------------------------------------- > > module IO_control(ALE,NWR,NRD,DIR,DA,MIN,MAX,SEL,TYPEFIL,AMPLIF,DIVFRQ,clk); > > input ALE; > > input NWR; > > input clk; > > input NRD; > > input DIR; > > input [7:0] MIN; > > input [7:0] MAX; > > inout [7:0] DA; > > output [7:0] SEL; > > output [7:0] TYPEFIL; > > output [7:0] AMPLIF; > > output [7:0] DIVFRQ; > > > > parameter uno = 8'b0000_0001; > > > > reg [7:0] ADDR_REG; > > reg [7:0] DO_REG; > > reg [7:0] SEL_REG=uno; > > reg [7:0] TYPEFIL_REG=uno; > > reg [7:0] AMPLIF_REG=uno; > > reg [7:0] DIVFRQ_REG=uno; > ^^^^^^^^^^^ > This initialization is illegal, or at least ignored by a synthesis > tool. > Use an external reset to actually initialize these registers. > > > assign SEL = SEL_REG; > > assign TYPEFIL = TYPEFIL_REG; > > assign AMPLIF = AMPLIF_REG; > > assign DIVFRQ = DIVFRQ_REG; > > Ummmmm...why not declare the SEL, TYPEFIL, AMPLIF and DIVFRQ outputs > as regs and not bother with this silly assign? Also: explicitly > declare whether your module outputs are wires or regs. It's a good > style habit. > > > assign DA = (DIR) ? 8'bzzzz_zzzz : DO_REG; > > > > always @ (posedge clk) > > begin > > if (ALE) ADDR_REG <= DA; > > > > if (~NWR) > > case (ADDR_REG) > > 8'b0000_0001 : SEL_REG <= DA; > > 8'b0000_0010 : TYPEFIL_REG <= DA; > > 8'b0000_0100 : AMPLIF_REG <= DA; > > 8'b0000_1000 : DIVFRQ_REG <=DA; > > default DO_REG <= 8'b1111_1111; > > endcase > > > > if (~NRD) > > case (ADDR_REG) > > 8'b0000_0001 : DO_REG <= SEL_REG; > > 8'b0000_0010 : DO_REG <= TYPEFIL_REG; > > 8'b0000_0100 : DO_REG <= AMPLIF_REG; > > 8'b0000_1000 : DO_REG <= DIVFRQ_REG; > > 8'b0001_0000 : DO_REG <= MIN; > > 8'b0010_0000 : DO_REG <= MAX; > > default DO_REG <= 8'b1111_1111; > > endcase > > end > > Umm, another style issue. Use more than one always statement for the > above. You have three separate registers; put 'em in their own always > blocks. > > Also: are ALE, NRD, NWR, DA all synchronous to your clock? > > Remember that ALE is a latch enable -- are you sure that your address > is actually valid when the latch enable is active and goes away? > > --aArticle: 65819
news@sulimma.de (Kolja Sulimma) wrote in message news:<b890a7a.0402061442.675b0195@posting.google.com>... > In germany for example Avnet and Insight are the only Xilinx > distributors for your FPGAs. These are huge distributors that have an > organization tailored for large customers with large orders. > (My last insight order involved about a dozen emails from me and > three letters from Insight. I can see that that is costly, but it is > unecessary) Avnet and Insight are the two biggies here in the states, too, and you're right -- they don't wanna talk to you unless you're buying multiple trays. Nu Horizons does have some stock of CoolRunners and I was able to buy a handful, but maybe I just got lucky. Arrow is usually much better about smaller quantities, but they don't handle Xilinx. DigiKey has a very limited stock of Xilinx stuff: smaller 95xx CPLDs (all CoolRunner stuff is non-stock, mutliples of a tray), old XC3K and XC4K parts (still very expensive, but if you need 'em they got 'em). They do have some Spartan 2 stuff, but it's really hit or miss. DigiKey really oughta be selling the CoolRunners. > Why don't you get yourself a small distributor in addition to these? > One without hundreds of FAEs. Without trade fair appearances that cost > hundreds of thousands of dollars. One that is happy to stock a number > of standard parts and make a 30% profit with them? Or just let us buy small (prototype) quantities direct from Xilinx! Yeah, X offers only three CoolRunner parts, 32 (real cheap), 64 (cheap) and 384 (expensive)! I actually didn't care too much that the 384 was expensive, but my design needed only a 128 and the 384 isn't available in the package I wanted. Yeah, yeah, yeah, complain complain complain. It's great if you have a relationship with a distributor, but once they find out that you only want to build a handful of prototypes or whatever, they're not interested. There has to be a way for the small garage shop guys to get parts. --aArticle: 65820
You know, we are all groping in the dark without having access to your design specifcaitons, board design, and test benches. 1. DCMs. Without seeing your design, I can only speculate how or if a DCM will help in your design. If you've used DCMs before, you probably considered it already. If you haven't, browse application notes from Xilinx and see if it will help in your situation. One possible reason is to simply generate a PLL. 2. Your original question (is it possible...): Where did you get your parts? Disty? Gray Market (dumpster diver)? 3. Try to meet 100 MHz timing. Look at the long paths. Fix these. E.g., move combinatorial logic from the Q side a flip flop to the D side of the flip flop. If you have a good version of Synplify, it can do some of this for you. 4. Do you have a clue where the failure is occuring? Off chip interface? Boundary between clock domains? Recommendation: Divide and conquer. E.g., run the dual port FIFO flags to pins and monitor those. If it repeatedly fails without any anomolies there, you know that is not your problem. I am groping in the dark not having your specification or implementation. But divide and conquer works best. 5. If the simulations are lengthy, by the time you read this, you could have run one long simulation. 6. If the problem is the different clock domains, it will be hard to find these problems. Xilinx have very small set/hold times, and it is actually hard to hit them in simulation, even if you try to get a setup and hold violation. Try modeling some random jitter on one of your clocks sources during the simulation, or sliding the frequency. 7. Do you have a self-checking test bench? 8. If you think it is between the clock domains, study your implementation of any status signals you are passing between the two domains. 9. Work with the software guys to develop test cases to narrow down a scenerio that makes the failure occur more often. 10. Have you put offset specifications in your UCF file? 11. Are you doing any fixed point multiplication? Do you have multi-cycle paths? Are you sure all of your signals are synchronous to the clocks they are sampled on. Anyway, these are all pretty generic obvious things too look at. Only you and your software guys can divide and conquer. "MM" <mbmsv@yahoo.com> wrote in message news:<c007rh$sqkst$1@ID-204311.news.uni-berlin.de>... > "William Wallace" <msm30@yahoo.com> wrote in message > news:7e4865b7.0402052324.1651ec26@posting.google.com... > > "MM" <mbmsv@yahoo.com> wrote in message > news:<bvmaua$u760t$1@ID-204311.news.uni-berlin.de>... > > > > Do a post PAR simulation. Note that xilinx uses the same times for > > min/typ/max in their sdf files. (Do a search in their web database > > for ways to get min sdf timing). Do min and max timing simulation. > > I did, although not the min/max... The problem with this is that I can only > simulate a few data frame cycles as it takes very long. Surely the problem > would have to manifest itself during the first frame, but I didn't see it... > Perhaps I need to repeat the whole thing... > > > > some > > > state machines, a bus interface and some Coregen memories. The bus runs > at > > > slower clock, but it is fully decoupled from the IP core (through the > > > memories). > > > > What are the two clock rates? Are you using dual ported FIFOs? Are > > they getting full? > > The clock rates are 38 MHz for the local bus and 50 MHz for the core and the > state machine that controls it. > > > Take the device that works and use a hair dryer to warm it, see if it > > fails. > > As soon as I get my hands on the hardware I will. At the moment my > management is satisfied with the thing working reliably at 45 MHz and all > the hardware went to software guys... > > > Look at using a DCM. > > Why? > > > Are you gating any clocks? > > No. > > /MikhailArticle: 65821
I tried to open the example of xapp529.pdf in EDK 3.2.2 but found the following error. Reading MHS file C:\xapp529\system.mhs... ERROR: system.mhs:120 Version 1.00.a of IP type xil_idct not found ERROR: system.mhs:126 Instance xil_idct_1 of type xil_idct is excluded from design What can I do for this Thanks for any replyArticle: 65822
I made a lot of changes (like the reset) , i'll post the new source soon!Article: 65823
"Georgi Beloev" <gbH8SPAM@beloev.net> wrote in message news:<1027j4slqdo2b24@corp.supernews.com>... > Hi Filippo, > > I assume the clk signal in your code is the AVR clock. You should implement > the interface asynchronously and when you have the data in the FPGA > synchronize it to whatever clock you have there. This is an excerpt from the > ATmega162L datasheet: > > "Note that the XMEM interface is asynchronous and that the waveforms in the > figures > below are related to the internal system clock. The skew between the > internal and external > clock (XTAL1) is not guaranteed (it varies between devices, temperature, and > supply > voltage). Consequently, the XMEM interface is not suited for synchronous > operation." > > Regards, > -- Georgi Teacher told us not to do an asynchronous interface , 'cause it won't work ... maybe he's just a crazy man... but a week ago it was asynchronous and didn't work tooArticle: 65824
Bassman59a@yahoo.com (Andy Peters) wrote in message news:<9a2c3a75.0402061216.7206d4cf@posting.google.com>... > Did you perform both pre- and post-route simulations? What does your > test bench actually do? Is it a real bus-functional model of your > microcontroller? Or are you just setting and clearing signals in some > arbitrary fashion? I would imagine that this is the root of your > problem -- your simulation is bogus. As they say: garbage in, garbage > out? > > What about your timing constraints? both simulations were succesful > This initialization is illegal, or at least ignored by a synthesis > tool. > Use an external reset to actually initialize these registers. > this has changed > > assign SEL = SEL_REG; > > assign TYPEFIL = TYPEFIL_REG; > > assign AMPLIF = AMPLIF_REG; > > assign DIVFRQ = DIVFRQ_REG; > > Ummmmm...why not declare the SEL, TYPEFIL, AMPLIF and DIVFRQ outputs > as regs and not bother with this silly assign? Also: explicitly > declare whether your module outputs are wires or regs. It's a good > style habit. > humm , i'll think about this > > assign DA = (DIR) ? 8'bzzzz_zzzz : DO_REG; > > > > always @ (posedge clk) > > begin > > if (ALE) ADDR_REG <= DA; > > > > if (~NWR) > > case (ADDR_REG) > > 8'b0000_0001 : SEL_REG <= DA; > > 8'b0000_0010 : TYPEFIL_REG <= DA; > > 8'b0000_0100 : AMPLIF_REG <= DA; > > 8'b0000_1000 : DIVFRQ_REG <=DA; > > default DO_REG <= 8'b1111_1111; > > endcase > > > > if (~NRD) > > case (ADDR_REG) > > 8'b0000_0001 : DO_REG <= SEL_REG; > > 8'b0000_0010 : DO_REG <= TYPEFIL_REG; > > 8'b0000_0100 : DO_REG <= AMPLIF_REG; > > 8'b0000_1000 : DO_REG <= DIVFRQ_REG; > > 8'b0001_0000 : DO_REG <= MIN; > > 8'b0010_0000 : DO_REG <= MAX; > > default DO_REG <= 8'b1111_1111; > > endcase > > end > > Umm, another style issue. Use more than one always statement for the > above. You have three separate registers; put 'em in their own always > blocks. > > Also: are ALE, NRD, NWR, DA all synchronous to your clock? > > Remember that ALE is a latch enable -- are you sure that your address > is actually valid when the latch enable is active and goes away? >
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