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
I believe Xilinx has a intermediate format that is not easy to reverse engineer. Sort of like object code for C programs. Perhaps other vendors have the same thing. I would not expect a code obfucator to do much for you. It removes the comments and renames the variables for C files. This certainly would make a VHDL file harder to modify, but it could still be reversed easier than an object type file. What is your goal? To prevent the multiple reuse by the customer? Or to prevent modification by the user? If you do obfucate the source, how would you support your customer if they have problems targeting the code? Johan Petersson wrote: > > Hi Chris, > > Good question, I have been considering it myself. I think there are > VHDL scramblers around. Let me know if you find one! > > Otherwize I'm planning to get someone to write one for me (rather simple > script hack using perl i think) - but it'll probably be some time before > I get that arranged :) > > Good luck, > Johan :) > > Chris Anderson wrote: > > > > Hi, > > I have a design for a device written using Renoir and ModelSim in VHDL. > > Initially it's targeted at a Xilinx Virtex. I need to generate an image > > of this VHDL in a form that is as flexible as VHDL (in terms of the > > ability to retarget) but is not in a human readable form so that it > > can't be reverse engineered. > > > > Any suggestions? > > > > Thanks > > > > Chris Anderson -- Rick 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 Arius 4 King Ave Frederick, MD 21701-3110 301-682-7772 Voice 301-682-7666 FAX Internet URL http://www.arius.comArticle: 25501
Hello;
First time posting here.. Hoping for some help.
I'm new to "doing the guts" of CPLDs and FPGA as I usually just plopped
them on the schematic and someone else did VHDL of the "guts".
Here is my issue:
I have a ABEL block that is a BCD to & segment LCD driver.
It has a phase input (for the LCD) and a Blanking input as well.
It works most of the time just fine but sometimes it sees an input bit as being
inverted from what it really is.
I can make an unrelated change in the schematic and the place of trouble
changes.
Sometimes I also get "impossible" outputs that do not even exist in the ABEL's
valid states.
Could someone please help me with what I could change in this code to be more
stable.
I am using Foundation 2.1i (they have not shipped 3 to me yet) SP VI and
am targeting an XC9500-PC84-15. Clock speed is 2.048MHZ but I am dividing it
down to 1HZ for most of the design.
Thanx
Rick
(P.s. this is a SPAM avoiding E-mail address . correct address
is my name(see above above)<at>ledinc.com
ABEL script attached below:
module BCD_7Seg
Title 'BCD_7Seg'
"4 BIT BCD TO 7 SEG LCD DRIVER WITH GLOBAL BLANKING and phase
Declarations
"/INPUTS
BCD3..BCD0 PIN; "BCD = [BCD3..BCD0];
BLANK PIN; "BLANK OUTPUT
PHASE PIN; "PHASE MODULATOIN
"/OUTPUTS
Q6..Q0 PIN istype 'com'; " was istype 'reg'
"Q = [Q6..Q0];
"/NODES
LCD6..LCD0 node istype 'com'; "was 'reg'
PD node istype 'com'; "invert PD LCD = [LCD6..LCD0];
truth_table ( [BCD3..BCD0] -> [LCD6..LCD0] )
0 -> ^B0111111;
1 -> ^B0000110;
2 -> ^B1011011;
3 -> ^B1001111;
4 -> ^B1100110;
5 -> ^B1101101;
6 -> ^B1111101;
7 -> ^B0000111;
8 -> ^B1111111;
9 -> ^B1101111;
"DASH OUTPUT BELOW AS ALL INVALID
10 -> ^B1000000;
11 -> ^B1000000;
12 -> ^B1000000;
13 -> ^B1000000;
14 -> ^B1000000;
15 -> ^B1000000;
Equations
PD = !PHASE;
Q6 = (LCD6 & !BLANK) !$ PD;
Q5 = (LCD5 & !BLANK) !$ PD;
Q4 = (LCD4 & !BLANK) !$ PD;
Q3 = (LCD3 & !BLANK) !$ PD;
Q2 = (LCD2 & !BLANK) !$ PD;
Q1 = (LCD1 & !BLANK) !$ PD;
Q0 = (LCD0 & !BLANK) !$ PD;
end BCD_7Seg
Article: 25502Hi Rick, (tronsmith is John L. Smith replying via Deja; my company's news-server didn't catch any of the replies on this thread) Thanks for your suggestion, no good deed goes unpunished. Here's some follow-on: Your response and Thomas' reply leaves me puzzled: Does "GCLK Optimization: ON" force signals off of the global routing network? Or does it keep them on it? I didn't see any indication of p-term clocks being used instead of GCLK in the fitting report for our design. This doesn't make any sense at all...what kind of an 'optimization' is it that breaks designs? (I've seen plenty of optimizations like that, doesn't make any more sense just for being common) Why would it be in there to begin with? If the designer has explicitly entered that he wants a signal on the global net, one would think the S/W should respect that. Assuming this is the culprit, does anyone know how to turn it off? I've been through and through the Xilinx Docscan, the only refs to 9500 options are in "Design Manager/Flow Engine Guide : Implementation Flow Options : XC9500 Implementation Options"; none of those mention GCLK optimization. "Use GCLK" is suggested for routing p-term clock onto GCLK, but nothing is mentioned about moving a GCLK onto a p-term. Searching "GCLK optimization" turns up zip. (I think in general, HITOP has been given short shrift in the documenation. PAR gets a whole chapter, but search on HITOP, and not much comes up) Repeating Thomas' original question, does anyone know how to keep the S/W from breaking the design? or is there a problem with the GCLK global routing to begin with? In article <39BD6297.121188A1@algor.co.uk>, Rick Filipkiewicz <rick@algor.co.uk> wrote: > > There's just one remote possibility that although you > have your clock connected > to a global clock input the > fitter isn't actually using the global routing. You > need to check at the fitting > report to see if there's a line likek > > Signall ``fooclk'' mapped onto global clock net GCK<n> > > and this at the end > > Global (GCLK) optimisation :ON Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25503
This is a multi-part message in MIME format. --------------D4355645021A4E410E6ACEDC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In many cases, it may not be necessary to mess with Gray code at all, simply by getting away from the Almost Full(or Empty) flag mindset that the IDT/Cypress/(pick your favorite FIFO) parts have left us in (not to mention Peter's app note ;o)). For a continuously active fifo moving data from a slower clock domain to a faster, simply use standard counters. Every eighth write to the input sets a 'readout request' flag that is re-sampled (two FF's) in the faster clock domain. The synch'ed request starts an eight cycle readout sequence. During the first cycle of that readout, an asynchronous reset is sent back to the request flag; in the eighth cycle, the synch'ed request is tested again to see if the fifo has another block of data. If so, the 8 cycle readout is repeated without a break. The circuit is reliable, and supports input clock rates as close as you care to get to the output clock rate without going over. I use it as a standard handler for video rate data, having long ago learned the TOTAL USELESSNESS of an empty flag for a high-speed fifo whose input clock rate approaches the output clock rate. ( I emphasize this for green designers who may have thoughts of using an empty flag...don't do it, you'll regret it. If you only have a single cycle to sample an empty flag, you will be burnt by metastability. Two cycles to sample may save you from from that, but means you can only support input clock rates up to 1/3 of the output clock: sample/sample/read/sample/ sample/read/etc.. ) This burst unload mechanism allows using any sort of counter you'd like, as long as the burst boundary is easily detected. The readout request sampling in the faster clock domain is overlapped with the readout operation for optimum efficiency. What is your application wzjohn? How close and what speed are your ins and outs? John rickman wrote: > > That depends on the rate and timing of data transfer. Although > oversampling may work for a FIFO count calculation, this is not the same > thing as clocking the data. The FIFO count will be off by one at any > given point in time depending on your luck in sampling, without ill > effect. But the data needs more care to not drop, change or overwrite > it. > > Ray Andraka wrote: > > > > By oversampling the counts for your comparison you are essentially turning the > > compare into a synchronous system. I think you still need the gray, at least as > > you've described it, to avoid sampling a transient state. It would seem > > however, that you could have gone to a totally synchronous fifo design with a > > oversampled rate match register on the slower side to accomplish the same thing. > > > > Dan Kuechle wrote: > > > > > > using the fast clock, I sampled the two address counters (clk #1), > > > converted > > > to binary (clk #2), and did the binary subtraction (clk #3). Nothing > > > elegent > > > here, but it worked, and not too expensive if your address counters are > > > small. > > > Now that the design is all working, I question whether I REALLY needed Gray > > > code address counters in the first place. > > > > > > wzjohn@my-deja.com wrote in article <8pkn1p$n8c$1@nnrp1.deja.com>... > > > > Hi, > > > > What is the cheapest way to determine the difference between two gray- > > > > coded values? My application is a FIFO with different input and output > > > > clocks. I would like to know approximately how full the FIFO is at any > > > > time: this information is needed in the faster clock domain. > > > > > > > > Or am I on the wrong track? > > > > > > > > TIA, > > > > > > > > wzjohn --------------D4355645021A4E410E6ACEDC Content-Type: text/x-vcard; charset=us-ascii; name="jsmith.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for John L. Smith Content-Disposition: attachment; filename="jsmith.vcf" begin:vcard n:Smith;John L. tel;work:858-320-4102 x-mozilla-html:FALSE url:http://www.visicom.com org:Visicom;Imaging Products adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA version:2.1 email;internet:jsmith@visicom.com title:Principal Engineer x-mozilla-cpt:;30864 fn:John L. Smith end:vcard --------------D4355645021A4E410E6ACEDC--Article: 25504
File this under "Why do they do it this way?" I'm putting together this little chip to average a bunch of samples. I have thirty-two sixteen-bit ADC channels. Each channel is independent. I need to average n samples of each channel. So, I figured I'd instantiate a bunch of RAM16X1Ds and go, instead of using the CORE Generator. So, I did. Fairly simple to do that sort of thing in VHDL. Time to perform functional simulation using the unisim library. The simulation failed. Everything was off by one clock tick. It turns out that everything in the unisim library has short (100 ps) VITAL delays, and the rest of my logic is written of course with no delays. The test-bench fix was to drive the RAM clock with a slightly-delayed version of the global clock, but clearly you can't do that if the memory is four levels down in the hierarchy, and I absolutely hate the idea of trying to maintain one version of code that's the "simulation" version, and the other that's the "to-be-implemented" version. Why do they put any kind of delay mechanism into something that's supposed to be used for functional simulations? When I do the logic design, I'm not concerned about timing! -- andy ---------------------------- Andy Peters Sr. Electrical Engineer National Optical Astronomy Observatory 950 N Cherry Ave Tucson, AZ 85719 apeters (at) n o a o [dot] e d uArticle: 25505
I've had exactly the same problem. This is how I got around it: In my simulator (Aldec), I made a copy of the library 'unisim', and then went through all of it, changing every '0.1ns', '0.01 ns', and so on, to '0.0ns'. (Thank goodness for Search&Replace) Then I recompiled that into the library "unisim_nodel". (for No Delay) n my source code, I include the unisim_nodel library, but I surround it with synthesizer directives indicating to ignore the use declaration: -- SYNOPSYS TRANSLATE_OFF library UNISIM_NODEL; use UNISIM_NODEL.all; -- SYNOPSYS TRANSLATE_ON When I do my simulation, it uses my timing-crap-free version of the library, and when I synthesize, it doesn't see the library and uses real components. Hope this helps. Note: I currently have a call to Aldec on this about the "officially sanctioned" way to do it. Note2: If you want a copy of my unisim_nodel library, I'll be happy to send it. -KentArticle: 25506
rickman <spamgoeshere4@yahoo.com> wrote in message news:39BA438C.11D2C0CF@yahoo.com... > Mark, > > The relationship between disti and manufacturer is not as well balanced > and even handed as you might think. The manufacturer often takes > accounts direct and cuts the disti out entirely. It is all based on > volume and price pressure. If the volume is high enough and especially > if the manufacture feels too much pressure to reduce prices, they will > cut the disti out and pocket the difference themselves. It is seldom > that the distis get an exclusive sales agreement with the large > manufacturers. Hi Rick, I'm aware of Xilinx's direct account policy but I was assuming that Andy isn't a direct account. > It is also often a *good* idea to speak directly to the manufacturers > rep as they can give you breaks on pricing that the disti can't, even if > you are ultimately buying through the disti. Of course this only works > if you are buying thousands of units. But even at 1000 pieces I have > gotten better pricing than what the disti would quote me. mmm....not so sure about this one, the disti is free to add his own margin but I still don't think the rep should be able to undercut him > > > Mark Harvey wrote: > > > > S. Ramirez <sramirez@deleet.cfl.rr.com> wrote in message > > news:Judu5.13363$98.1346052@typhoon.tampabay.rr.com... > > > Andy, > > > Earlier, I posted a message to the newsgroup that explained how the > > > disties work and what their motivations are. A large amount of their time > > > is spent "registering" parts. > > > > Because that's the only way that they get lower pricing from Xilinx - it's > > what > > Xilinx want them to do. > > > > > You are correct in saying that they will jump all over you asking > > those > > > silly questions, because they are trying to build a case for registering > > the > > > design socket with, of all people, the Xilinx manufacturer's rep (Xilinx > > > rep)! > > > What you should do is get in touch with the Xilinx rep yourself. > > This > > > is the person that the disty will go to to get availability and price > > > information, so why not go there yourself? With Virtex-E parts, > > > availability and other information are scarce, and the disties are forced > > to > > > go to the Xilinx rep for the answers. > > >Tell the rep that you do not want any > > > disties in on your design. Explain to him/her that you are not interested > > > in a bunch of people bothering you "on this one." They will keep the > > > information to themselves and not involve the disties. > > > > If the rep in my area did this, the disties run would screaming to Xilinx, > > no rep should ever do this, after all the rep can't sell the parts, only the > > disties. > > > > > The exception to the above is if you need parts that are well > > > established. In this case, the disties may have parts on their shelves. > > If > > > they do, great, but if they don't, they will have to go to the rep again. > > > > Why, he certainly doesn't have any on HIS shelf! > > > > > In either case, you will have the salesperson or the FAE knocking on your > > > door or calling you up for the same reason -- to gather information in > > order > > > to register the part. > > > So my advice is, if you don't want the disties to come give you a 2 > > hour > > > PowerPoint presentation on why they are the chosen ones, to call the > > Xilinx > > > rep yourself regardless of the part. Let the rep find the parts for you > > at > > > the disty warehouse or factory. > > > > What's the point of asking the rep to ask the disty? ..and if the rep sells > > direct from factory, the disty should immediately complain to Xilinx. > > > > That way you will minimize disty PowerPoint > > > presentations and obnoxious questions. > > > > Better just to tell the disty to leave his powerpoint slides at home. > > > > At the end of the day, all Xilinx devices sold thru the disties must > > undergo the design registration process, it's better to build a > > relationship with a disty that you trust, who gives good tech support & > > service and let > > him/her register all your designs - that way he/she is guaranteed lower > > pricing from the rep & has further incentive to keep giving you support. > > > > Use the design registration as a carrot on a stick to wave in front of the > > disty.....no support, no registration. > > > > > By the way, this is true of most semiconductor companies, not just > > > Xilinx. > > > -Simon Ramirez, Consultant > > > Synchronous Design, Inc. > > > > > > > > > > > > "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message > > > news:8pbfj5$16qm$1@noao.edu... > > > > I really hate to ask silly questions like this, but I hate calling the > > > > distros because once you tell them you're thinking about considering > > > > thinking about using a part in a design, they jump all over you because > > > > they think you're gonna be writing a req for 10,000 parts tomorrow ... > > > > > > > > I'm looking at doing a VirtexE design. XCV50E should be big enough. > > > > Mainly, I want the LVDS I/O. Are they available now, or will they be > > > > available in the next couple of months? > > > > > > > > Of course, I could probably do the design with external LVDS parts, but > > > > this seems like a "neat" solution. > > > > > > > > -- andy > > > > ---------------------------- > > > > Andy Peters > > > > Sr. Electrical Engineer > > > > National Optical Astronomy Observatory > > > > 950 N Cherry Ave > > > > Tucson, AZ 85719 > > > > apeters (at) n o a o [dot] e d u > > > > > > > > > > > > -- > > Rick 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 > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 25507
S. Ramirez <sramirez@deleet.cfl.rr.com> wrote in message news:foCu5.18606$98.2061199@typhoon.tampabay.rr.com... > > Because that's the only way that they get lower pricing from Xilinx - it's > > what Xilinx want them to do. > > --This is true. The design registration process guarantees that Xilinx will > sell to the disty owning the registration at a lower price, thus allowing > that particular disty to undercut the other disties and get the sale (unless > the buyer is playing games). > > > If the rep in my area did this, the disties run would screaming to Xilinx, > > no rep should ever do this, after all the rep can't sell the parts, only > the > > disties. > > --The rep in your area has no balls. If the rep has reason(s) to withhold > information from the disties, then (s)he should do it, unless of course > (s)he is YOUR rep. The rep in my area certainly doesn't lack any balls! My reps have always honored my requests to withhold > information. I give them reasons to, and they do it. I've seen disties run > to the rep screaming, after the design cycle is over, that they helped me > throughout the design process, and that without them, I couldn't have pulled > it off. The rep(s) have all seen this before, knowing that sometimes the > disties claim they did a lot of support work when in fact they didn't. that's a different story, if the disti is being dishonest, then sure, go ahead and tell the rep and/or Xilinx. In > the final analysis, it all boils down to money. The disties want to make > money on every deal, support or no support. Err. yes, like most corporations in this world they exist to make money for the stockholders and employees - don't see any problem with that. > The reps will always jump at a chance to make MORE money if you give them a good enough reason. Just like the disti ;) > Andy's request to keep the disties out of the picture so that he doesn't get > bothered by them would be honored by my reps. > > > What's the point of asking the rep to ask the disty? ..and if the rep > sells > > direct from factory, the disty should immediately complain to Xilinx. > > --I've seen disties complain and lose. Xilinx wants to make money and > sometimes that takes disty involvement. However, if the disties did not > help me one bit or one byte, and the local Xilinx rep can make more money if > (s)he leaves the disties out of the picture, I guarantee you again that the > disties will lose. > The disties basic recourse is to escalate the matter > above the local rep, and they better have a damn good story. But from my > experience, all it takes is the higher authority making a few phone calls to > find out the several perpectives, including mine! The final result may be > losing this particular sale and possible future ones, since they P.O.ed the > rep. Again, if the disti has been dishonest or exaggerated his/her tech support, then they deserve to be put in their place. > > > Better just to tell the disty to leave his powerpoint slides at home. > > --Some disties can't talk to engineers without a PowerPoint presentation. > They just aren't technical enough to pull it off. Just start asking hard > questions, and they'll say "I'll get back to you on that." > > > Use the design registration as a carrot on a stick to wave in front of the > > disty.....no support, no registration. > > --I agree with you here 100%. I bet that if Andy, the original poster, had > a darn good Xilinx specific disty FAE, he wouldn't have the problem he is > having. His problem (my opinion) is that the disties are asking him a lot > of questions, contributing nothing to his cause, wasting his time, and they > are still getting the registration! But somebody, somewhere HAS to register the design. > Therefore, what they're doing works for > them. > > -Simon Ramirez, Consultant > Synchronous Design, Inc. > >Article: 25508
S. Ramirez <sramirez@deleet.cfl.rr.com> wrote in message news:YA9v5.40366$58.5311575@typhoon.tampabay.rr.com... . > --If you are browsing through the Xilinx web site, and that action caused a > distributor to call you, then this means that the Xilinx rep turned him on > to you. It is the rep that gets this "report" from Xilinx. The fact that > the disty called you tells me something -- the rep and one of the disties > are very tight with each other. Is it only one disty that seems to be > favored this way? > > When you register for WebPack, you are asked to specify a preferred disti (or indicate no preference) - the "lead" will be passed on to that disti.Article: 25509
> > This is not correct... At least not according to MIPS's lawyers. MIPS is > currently suing Lexra for doing software emulation of some patented > instructions (LWL, LWR, SWL, and SWR to be exact). Of course > Lexra's lawyers would disagree. > 1) What do these instructions do? (They look like 'word shift' type operations....) 2) Did they patent the instruction menomic or what the instruction did? If its the latter then a patent has been issued for an algorithm. I do hope its not a commonly employed one - I can't think of any operations at the register level that haven't been implemented in some machine or another over the last five decades. 2a) Then there's the issue of instruction emulation by microcode. This sounds fancy and modern but the technique has been around for decades - its the logical way to implement complex instructions on a processor. Emulating other people's instructions isn't new. I first became aware of a machine that could do this in the mid 70s - it was offered as a way of running software from a new range of computers and the company's legacy systems. 2b) I think everyone agrees that the patent office needs reinventing. It currently does more damage than good in our business, IMHO. 3) Intel didn't patent their instruction set. They copyrighted it. That's why NEC had to come up with creative alternative names for the same instructions in their 'V' series. AMD and the like were OK due to some second sourcing agreement. 4) I've got a real 'thing' about people who patent bullshit things, especially if they really believe that they invented this stuff. It takes a special combination of arrogance and ignorance to believe that you have truly invented something basic in our trade. They need to humble up, learn a bit, and maybe work hard enough to actually invent something new.Article: 25510
>>>>> "Martin" == Martin Usher <martinusher@earthlink.net> writes: [snip] Martin> 4) I've got a real 'thing' about people who patent bullshit Martin> things, especially if they really believe that they invented Martin> this stuff. It takes a special combination of arrogance and Martin> ignorance to believe that you have truly invented something Martin> basic in our trade. They need to humble up, learn a bit, and Martin> maybe work hard enough to actually invent something new. [facetiousness on] I have a patent pending on the use of the * character in `C' code. And may I say I am brilliant for deciding to finally use this character that is defined in the `C' standard, IMHO. This explains why C++ has a novel use of the "&" character. Please switch now or be sued. [facetiousness off] BillArticle: 25511
Andy and others, How about recompling UniSims with the RAM's "timing checks on" generic set to false? This is what I've been doing since last year, and so far it's been working fine. (At one point I concerned stuff like the IEEE libraries and UniSims to be sacred and untouchable. No more; these days I routinely recompile them all...) I find it incredible that timing checks in UniSim are ON by default, but displaying error messages is OFF by default (with timing checks on, in functional simulation, you'll get error messages all over for 0ns holds) . Bizarre. ---Joel KolstadArticle: 25512
Joel, I'm not sure about this, but won't turning off the "timing checks on" generic only disable the timing checks? What it won't do is prevent the instantiated components from having delays. Or am I mistaken here? >I find it incredible that timing checks in UniSim are ON by default, but >displaying error messages is OFF by default (with timing checks on, in >functional simulation, you'll get error messages all over for 0ns holds) That's something else I found odd. Using Xilinx tools, you get errors for 0ns holds, but looking in the data sheet, 0ns holds are *okay*. <shrug> -kentArticle: 25513
Rick, Thanks this is excactly what i mean, so now i am sure. Richard rickman wrote: > I think I understand your question. You are not sure which positive edge > of the clock registers the data, S2 or S3. The problem is that the > simulator does not show any delay (other than perhaps the minimum timing > resolution) and makes the outputs of the FFs look like they change at > the same time as the clock edge. Really they are slightly delayed. > > Let me draw a picture that is how the signals really are. > > | S1 | S2 | S3 | > ___ ___ ___ > CLK ___| |___| |___| |___ > ____ ______ ______ _____ > Data ____><__1___><__2___><_____ > ____ ______ ______ _____ > FIFO ____><______><______><__2__ > _____________ _____ > WREN \_______/ > > Here it shows that the data from the RAM changes just after the rising > edge of the clock. So the data that is latched into the FIFO is the data > that was stable before the clock edge and not the new data that comes > *after* the clock edge. > > Is that more clear? > > Richard Meester wrote: > > > > Hi all, > > > > i have a general question regarding some timing issues. I am doing a > > project connecting an fpga to an extern synchronous dpram. This dpram > > has 1 cycle delay in pipelined operation. > > > > the problem i am having has to do with timing and enabling of flipflops > > etc. > > Currently i have a state diagram as follows. > > s1 : output address on bus. > > s2 : enable writeenable of internal fifo. > > s3: -- at this point the data is clocked in from the external address > > bus into the internal fifo. > > > > When i do a functional simulation i see indeed that the enable of the > > internal fifo goes high at state2 (excactly at the positife clock edge). > > But does it now start clocking in the data at this point, or on the next > > clock cycle (and thus the time when we are in state 3.) In simulation is > > see that at the clock pulse of S2 the enable goes high, but i don't know > > if the data is now clocked in or not. I presume that the data is clocked > > in on the next clock cycle, since the enable signal is set in state 2, > > and state 2 is relative to a pos_edge clock, and thus at the rising edge > > of the clock the wr_enable line was not high, and thus the data should > > not be clocked in at S2, but at the next cycle. > > > > Thanks in advance, > > > > Richard > > > > -- > > Quest Innovations > > tel: +31 (0) 227 604046 > > http://www.quest-innovations.com > > -- > > Rick 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 > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.com -- Quest Innovations tel: +31 (0) 227 604046 http://www.quest-innovations.comArticle: 25514
I also ran into the same thing. When you instantiate the clocked unisim components, set the TimingChecksOn generic to "FALSE" to disable the timing crap. You'll also have to surround the generic in the declaration with syn_translate on and off pragmas to keep the synthesis from complaining. For example: component FDCE --synthesis translate off generic(TimingChecksOn: Boolean := FALSE); --synthesis translate on port (D,C,CE,CLR : in std_logic; Q : out std_logic); end component; attribute syn_black_box of FDCE:component is true; "K. Orthner" wrote: > > I've had exactly the same problem. > > This is how I got around it: > > In my simulator (Aldec), I made a copy of the library 'unisim', and then > went through all of it, changing every '0.1ns', '0.01 ns', and so on, to > '0.0ns'. (Thank goodness for Search&Replace) > > Then I recompiled that into the library "unisim_nodel". (for No Delay) > > n my source code, I include the unisim_nodel library, but I surround it > with synthesizer directives indicating to ignore the use declaration: > > -- SYNOPSYS TRANSLATE_OFF > library UNISIM_NODEL; > use UNISIM_NODEL.all; > -- SYNOPSYS TRANSLATE_ON > > When I do my simulation, it uses my timing-crap-free version of the > library, and when I synthesize, it doesn't see the library and uses real > components. > > Hope this helps. > > Note: I currently have a call to Aldec on this about the "officially > sanctioned" way to do it. > > Note2: If you want a copy of my unisim_nodel library, I'll be happy to send > it. > > -Kent -- -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 or http://www.fpga-guru.comArticle: 25515
Johan, Johan Petersson wrote: > Hi Richard, > > Why don't you try and synthesize your design, do a preliminary backend > implementation > in your favourite architecture and finally generate a back annotated > vhdl-netlist? > > That should be feasible in any gate array with any normal tools these > days. > > If you are working with Xilinx fpga's i could send you a makefile that > shows, > among other things, how the back annotated netlist is generated. > > Good luck, > Johan :) > > ps It will be very difficult for anyone to give you a good answer to > your > question unless you include the source code for your state-machine and a > detailed > timing diagram of your memories. Further - I guess you would like to > have some > kind of information about the pcb/pcbs that you will put your stuff on. > What kind of info about the pcb/pcbs. I lokated the dpram close to the fpga as possible, so there should be no problem there. and the rest is straight forward (i think). Richard > > Is your fifo in the FPGA by the way? To answer your fifo question i > would have > to know something more about the fifo as well... > > Richard Meester wrote: > > > > Hi all, > > > > i have a general question regarding some timing issues. I am doing a > > project connecting an fpga to an extern synchronous dpram. This dpram > > has 1 cycle delay in pipelined operation. > > > > the problem i am having has to do with timing and enabling of flipflops > > etc. > > Currently i have a state diagram as follows. > > s1 : output address on bus. > > s2 : enable writeenable of internal fifo. > > s3: -- at this point the data is clocked in from the external address > > bus into the internal fifo. > > > > When i do a functional simulation i see indeed that the enable of the > > internal fifo goes high at state2 (excactly at the positife clock edge). > > But does it now start clocking in the data at this point, or on the next > > clock cycle (and thus the time when we are in state 3.) In simulation is > > see that at the clock pulse of S2 the enable goes high, but i don't know > > if the data is now clocked in or not. I presume that the data is clocked > > in on the next clock cycle, since the enable signal is set in state 2, > > and state 2 is relative to a pos_edge clock, and thus at the rising edge > > of the clock the wr_enable line was not high, and thus the data should > > not be clocked in at S2, but at the next cycle. > > > > Thanks in advance, > > > > Richard > > > > -- > > Quest Innovations > > tel: +31 (0) 227 604046 > > http://www.quest-innovations.com > > -- > APZ FOR MEN BECAUSE FIRST IMPRESSIONS LASTS -- Quest Innovations tel: +31 (0) 227 604046 http://www.quest-innovations.comArticle: 25516
"K. Orthner" <korthner@hotmail.nospam.com> schrieb im Newsbeitrag news:8FAEA273Dkorthnerhotmailcom@158.202.232.7... > That's something else I found odd. > Using Xilinx tools, you get errors for 0ns holds, but looking in the data > sheet, 0ns holds are *okay*. Look at the Xilinx note " How can hold time violations occur when the data book states 0 ns hold times? " at http://support.xilinx.com/techdocs/782.htm for this question. If you use the ModelSim you can turn the switch "disable vital timing checks" on and the simulation runs without setup/hold error messages and all the 'X's in the RAMs are gone (was gone in my simulation). TobiasArticle: 25517
Ray, You mean I didn't have to go recompile the unisim libraries? It's as easy as setting the generic to FALSE? Then all the nasty timing ptoblems go away? ray@andraka.com (Ray Andraka) wrote in <39BF2224.8921F01@andraka.com>: >I also ran into the same thing. When you instantiate the clocked unisim >components, set the TimingChecksOn generic to "FALSE" to disable the >timing crap. You'll also have to surround the generic in the >declaration with syn_translate on and off pragmas to keep the synthesis >from complaining. For example:Article: 25518
Hi Simon, thanks for your answer. In my case the parallel input works fortunately, but some of the logik detecting slopes in slow impulse trains does fail. Interestingly enough, there seems to be a lot of experiences in this group with similar problems, but I haven't heard anything from XILINX yet. Thanks, Thomas PS: Simon, despite your experiences with synchronizers you call your company still Synchronous Design ? ;-)Article: 25519
That clarifies it a lot for me, Tobias. Thanks! Tobias.Stumber@de.bosch.com (Tobias Stumber) wrote in >Look at the Xilinx note " How can hold time violations >occur when the data book states 0 ns hold times? " at >http://support.xilinx.com/techdocs/782.htm >for this question.Article: 25520
In article <0bvv5.256972$1h3.4986622@news20.bellglobal.com>, "Nestor" <nestor@ece.concordia.ca> wrote: > Thanks to everyone for the replies. The declaration of a package with probe > signals seems to be good enough for my purposes. I will need to try it out, > most likely tomorrow. > > Nestor > If you use Modelsim, the simplest way is to view the signal in a list (using strobe option with the period you want), then save the list as TSSI. You will have a text file with values written on a column. Adrian Sent via Deja.com http://www.deja.com/ Before you buy.Article: 25521
Are you lot talking about the logical shape or the physical shape? From what I've seen looking at the encapsulation, the real device is square and this would makes sense as the package is also square. "rickman" <spamgoeshere4@yahoo.com> wrote in message news:39BE904A.9CEC66A2@yahoo.com... > I think he is asking why the rows and columns are not the same count in > contrast to many of the other Xilinx families. I don't know that anyone > would care that the die itself is not square. In fact many memory chips > are made rectangular just so they will fit in the packages. > > I can't say why Xilinx chose non square arrangements of the CLBs. Some > of their chips are square and some aren't. Maybe the CLBs are not square > and they adjust the rows and columns to make the die square??? ;) > > > Johan Petersson wrote: > > > > Hmm, > > > > No idea, but it isn't the only non square chip around. Not that I'm an > > expert > > on chip squareness :) I think the terrible hole-mounted 5000 pld's from > > Altera > > were squre, and some memory chips are square, aren't they?? > > > > Maybe it's a question of bonding the signals out from the chip to the > > pins - or > > maybe internal routing efficiency... > > > > Who knows, > > Tell me if you get the answer somehow! > > > > --JOHAN :) > > > > erika_uk@my-deja.com wrote: > > > > > > hey, > > > > > > why virtex chips are rectangular and not square > > > > > > --ERIKA > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > -- > > Rick 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 > > Arius > 4 King Ave > Frederick, MD 21701-3110 > 301-682-7772 Voice > 301-682-7666 FAX > > Internet URL http://www.arius.comArticle: 25522
Thomas Falk wrote: > > Hi Simon, > > thanks for your answer. In my case the parallel input works fortunately, > but some of the logik detecting slopes in slow impulse trains does fail. Can you clarify 'slopes in slow inpulse trains' - are these slow edges, and how many registers do they feed ? -jgArticle: 25523
On Tue, 12 Sep 2000 12:39:54 GMT, kolja@prowokulta.org wrote: >For many applications where a PWM is used a Delta-Sigma DAC gets even >better results. There is a Xilinx applications note XAPP154 on how to do >a 8-Bit S-D DAC in 10 LUTs plus 17 Registers => 9 Slices >This would result in 567+epsilon Slices and would fit in a XC2S50. This isn't for high-resolution D/A work (which is lucky, since your notes go right over my head! :-) >If all the PWMs are synchronous (They use the same PWM cycle) >one counter and 64 comparators with 8-Bit input register and >one bit output register should be sufficient. Yes, they are, and that approach did occur to me. Would it be simpler than 64 simple ripple counters? >This would reduce the hardware cost to one LUT per Bit or 5 Slices per >channel or 320+epsilon Slices total. (A loose fit in a XC2S30) Thanks for the advice!Article: 25524
On Tue, 12 Sep 2000 11:59:31 GMT, Ray Andraka <ray@andraka.com> wrote: >what is the available clock and required sample rate? If you can supply a >multiplied clock, you can reduce the size of the logic substantially. It's pretty slow - the PWM time-slice is probably no less than 1us. I'll have to read up on these "multiplied clocks", since they seem to be the key to success :-) Thanks for your help, folks!
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