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, that is the problem. the report doesn't say anything much. I traced any opb_intc_0/Intr<1>, and it is driven by the interrupt signal from the uart block. this will work fine if it is connected standalone. Chris VC wrote: > <snip> > > Its not a matter of resources. > > As the error message says - > " output > signal=opb_intc_0/opb_intc_0/INTC_CORE_I/INTR_DET_I/interrupts<1> has > input > signal "opb_intc_0/Intr<1>" which will be trimmed. See the trim report > for details about why the input signal will become undriven" > > The signal - opb_intc_0/Intr<1> is undriven due to some reason; you > need to figure that out why and see what needs to be changed. > > HTH.Article: 113451
"bijoy" <pbijoy@rediffmail.com> wrote in message news:eea0fde.-1@webx.sUN8CHnE... > Hi In designing asynchronous FIFOs we have to use Gray code read/write > pointers. > > And while using gray code I know how to generate full and empty flags. > > But i would like to get ideas from experienced designers how to generate > Programmable full or programmable empty flags > > Thanks in advance > Not to put a damper on the thread but I've found that there are probably very few applications for true programmable fifo flags inside a programmable chip that can be in-system updated like an FPGA. By 'programmable flag' I'm assuming that we're talking about having some register that can be written to with some arbitrary number that will cause some associated fifo status flag to trigger when it reaches that level. This arbitrary number is in some fashion controlled by software and is not and can not be known a priori. There are applications where I'd like a flag to go off at 'almost full' or 'almost empty' but those 'almost' conditions have always been able to be determined as hard fixed constants. Maybe those levels are things like 7/8 or 321/456 or .01 (just making up numbers here) but the point is that the point where I want a fifo flag to trigger has (for me at least) always been traceable back to known system parameters. It could be that the trigger level is some bizzarro function of those system parameters but the end result is a known fixed number so generally what I will do is code the bizzarro function into the VHDL that instantiates the fifo to produce the constant that will be input as a generic input to the fifo that uses it to determine the flag status trigger levels. True programmable flags where some outside software comes in and actually tells the fifo what specific level to trigger at came about back when fifos were mostly implemented as discrete parts and the suppliers of these little gens of course would have virtually no market for parts that trigger at levels like 7/8 or 321/456 or .01 so instead they came up with a mechanism to allow the user to program in an arbitrary level...which they did....and always (in my experience) did so with some constant that was determined from system parameters. For those applications that fit the cases I've described and really can have fixed constants to determine possibly bizzaro trigger levels there is no need for any convoluted math or moving gray code to binary to do math. Your gray code counter that keeps track of the depth is a finite state machine, there is exactly one state that needs to be matched to see if it corresponds to the equivalent of being 321/456 full. If someone does have an application that really requires true programmable flags I'd be interested to hear about it. The environment though is - Fifo is inside a programmable part. - That programmable part can be updated in system. Presumably this would have to mean that the trigger levels can not be determined either empirically at design/design verification time or as a function of known system parameters but would (presumably) have to be a dynamic function of what is going on in a particular system at a particular time (i.e. something unique to the particular system at that point causes the software to go 'Woooah, I need to change that fifo trigger level from 321/456 to 7/8 (or some such)'. KJArticle: 113452
ashish.dobhal@gmail.com wrote: > In the presence of numerous styles for designing asynchronous FIFOs, > how does FPGA synthesis tools infer the FIFO specified in RTL? > > Thanks in advance. > > Ashish I know of no tool that infers FIFOs, async or synchronous. Tools infer shift registers and dual-port memories (1 Write, 1 or more Reads) fine. Shift registers can be used in FIFOs. The FIFOs still need coding for address control and flag generation. Without that coding there would be no chance of inference. Since there are so many ways to code the address and control, there probably is no standard inference. If the architecture supports hard FIFOs, instantiate them or generate them from the vendor's tools.Article: 113453
Hello, did anyone know how to realize a CMI Coder/Decoder in a FPGA (preferred in VHDL). Thanks for answers an tipps. VolkerArticle: 113454
<rponsard@gmail.com> ha scritto nel messaggio news:1166010235.979393.32660@16g2000cwy.googlegroups.com... >I don't need your IP secrecies... > > This is for my students : what, in your current design, requires using > a fpga + softcore, in place of a COTS micro controler ? > less IC -> lower footprint, lower power cons., parallelism,... > > thanks, > raph > Chip customization VS asic project. MarcoArticle: 113455
On 10 Dec 2006 13:15:40 -0800, burn.sir@gmail.com wrote: > >In an interview from 97, Bob Yannes the designer of MOS 6581 (aka >"SID") said the following aboud the chips ASDR enveloper: > >"In order to more closely model the exponential decay of sounds, >another look-up table on the output of the Envelope Generator would >sequentially divide the clock to the Envelope Generator by two at >specific counts in the Decay and Release cycles. This created a >piece-wise linear approximation of an exponential. I was particularly >happy how well this worked considering the simplicity of the circuitry. >The Attack, however, was linear, but this sounded fine." > >In short, he was using an down-counter to count down from 255 down to >some number, but he somehow made the counter to move >pseudo-exponentially instead of linearly. > >Does anyone know how this works? > > >burns > > >(the whole interview is found at >http://stud1.tuwien.ac.at/~e9426444/yannes.html) You can model a simple exponential decay: Given integer N in a register, iterate... N = N - K * N where K < 1. One simple value for K is 0.5. So N drops in half every iteration. A little less severe is .25 (right shift 2) or 0.125 (shift 3) etc. The smaller K, the more this looks like an exponential decay, and the slower it decays. It won't ever get to zero unless you compute to more bits than you actually use, namely throw away some LSB guard bits. JohnArticle: 113456
"Andy" <jonesandy@comcast.net> schrieb im Newsbeitrag news:1166052157.531419.185640@l12g2000cwl.googlegroups.com... > Why do you need to connect the same clock to more than one clock input > on your FPGA? What kind of FPGA are you using? > > If I had to buffer and translate, I would rather translate, then > buffer. Unless you are very careful with your resistors and > interconnect, a resistor translator may not work too well. > > Andy Thanks so far for your answer. I'm using Virtex-4 FX60. Depending on the implemented designs I will use either the clock input on one side or the other, not both the at the same time of course. So I'm hoping for more flexibility and freedom of clock routing if I have two clocks available and stick to the one that fits better from design to design. The FPGA's input is LVDS.Article: 113457
Brian Drummond wrote: > On 12 Dec 2006 05:41:46 -0800, paulcullen@purewebsites.co.uk wrote: >>What is the sign-and-magnitude of the following 4's complement >>number? (Leave answer in base 4). (snip) > Be aware that the answer depends on the word size - if it's a 16 bit > number I'd give one answer; if it's larger (say 32 bit) I'd give another > answer. You mean 8 quits, not 16 bits. bits, trits, quits, quints, ... -- glenArticle: 113458
Koen Van Renterghem wrote:
> Hi,
>
> I'm trying to devise an efficient method to generate a ones' complement
> sum of two 16 bit integers in a single cycle. I'm targeting a Xilinx
> device and right now I'm using a 32 bit adder. Suppose I want to add x
> and y :
You need the end-around carry. It is pretty easy with a carry
lookahead adder to wire the carry out back to the carry in.
(snip)
You should only need a 16 bit adder with carry in/carry out.
How about:
assign {carry,result} = a+b+carry;
The worst case is where the carry propagates 16 bits.
(Well, the full width.) It never goes farther than that.
-- glen
Article: 113459Symon wrote: (snip) > Weeeelll, yes and no! I was just trying to make a point that there is a > finite probability that the lights will stay red until the drivers drop dead > of old age. Not exactly safe! Nearly, but not exactly. :-) Likewise, the > PDP-10 console lights _could_ stop for months. > So, I would respectfully disagree with your statement that "The solution to > metastability is asynchronous logic (also called self-timed logic).". > Furthermore, the implication that synchronous design is any worse than > asynchonous design I think is not true. As Mike said in his post, "The > D-flop is also an asynchronous circuit.". There is also a finite probability that all the air molecules in the room will move to the other half of the room. Like metastability the solution is also exponential. If you have a mechanical traffic controller, cams springs and such, then it might last that long. Electrical I don't think so. Not so long after I learned about metastability, among others that the lower probability of getting to the metastable state the longer it stays when it gets there, I was in a shower with a valve with a spring to turn off when you release it. It would turn such that it would go over the cam to the other side. I managed to get it to stop right on top, the metastable state, long enough to finish a shower. -- glenArticle: 113460
rponsard@gmail.com wrote: > I don't need your IP secrecies... > > This is for my students : what, in your current design, requires using > a fpga + softcore, in place of a COTS micro controler ? > less IC -> lower footprint, lower power cons., parallelism,... There are two levels of softCPU apps : a) The tiny ones, where the code fits inside the FPGA, in BRAM. b) The larger ones, that need external code memory. For a) the SoftCPU comes almost for free, and can be used to handle less time-critical tasks, and give a degree of programmability to all the other FPGA coded peripherals. Or they may be DSP(s), doing focused tasks. Unless you need ADCs / DACs, or similar peripherals, these do meet the lower footprint consideration. For b) once you have to add Code memory, you've lost the 'single chip', and the interface between the memory/fpga is poor for RFI & pin count. Now it's becomes less clear-cut on which is better, and the choice swings somewhat, as each alternative goes thru generation cycles, or as code size changes. If your code CAN fit into an external 32 bit uC, and meet speed targets, the tight local bus Code-CPU, gives the uC quite an edge. Better 32 bit uC now have DMA SSC channels, so FPGA interfaces can have low pin counts, and they have quite impressive FLASH resource, so the SoftCPU can struggle against this growing option. Leading example: Atmels upcomming AT91SAM9XE512 Flash uC. Once your app gets so large (MBytes), that is has outgrown uC Flash, and it needs SDRAM to run, then it swings more balanced. SDRAM uC are appearing, but not widely yet (example: AT91SAM9263), and both choices have PCB traces to SDRAM, so there less of a clear edge. Also, show your students this: http://www.eetimes.com/news/latest/showArticle.jhtml;jsessionid=HAHXOJ0RM2UHYQSNDLSCKHA?articleID=196603670 Details are presently sketchy, but a large dual port memory that was not niche-priced, would be interesting indeed to FPGA + SoftCPU + uC trade offs. -jgArticle: 113461
nospam wrote: (someone wrote) >>>What about injecting noise in the FF feedback loops which is small >>>enough not to alter their (static)performance, but large enough to drive >>>the feedback loops (and maybe schmitt triggers) into clipping and thus >>>their stable state ? > It is an idea I proposed before, without any claim that it would reduce the > occurence metastable states only that it would reduce their duration. As I understand it, the area under the (probability of going metastable) vs. (time staying metastable) tends to be constant. It might be that you can change the distribution enough to make it more useful. -- glenArticle: 113462
I am re-posting this, since I have not got any response from anyone... If somebody can help me solve this problem.. please... Even if I remove my SDRAM controller completely and just keep sending NOPs to SDRAM with A9, A10, A11 connected, the board hangs. so I think the problem is not with the Controller code... It is somethingelse that I might have missedout. thanks Mohni. Amirtham wrote: > Thanks for your response. > > I am making > > 1) A10 = 0 for READ and WRITE to disable AUTO-PRECHARGE since I am > using burst transfer. > > 2) A10 = 1 for PRECHARGE command to precharge all the banks. > > Thanks!!! > > > Ben Jackson wrote: > > On 2006-12-08, Amirtham <amirtham@microview-tech.com> wrote: > > > > > > If I access SDRAM using address lines sdr_A8 to sdr_A0, I am able to > > > access one row 100% correct without error. My problem starts if I > > > connect sdr_A11, sdr_A10, sdr_A9. Board hangs. > > > > Do you understand the special function of A10 for READ and WRITE commands? > > What is your address logic for read and write? > > > > -- > > Ben Jackson AD7GD > > <ben@ben.com> > > http://www.ben.com/Article: 113463
Sorry, I should have said. This is going to be using synchronous burst mode components.Article: 113464
lbo_user wrote: > Sorry, I should have said. This is going to be using synchronous burst > mode components. That makes the interface simpler (once in synchronous mode), but if you read the datasheet, the devices power up (and end up after reset) in **asynchronous** mode. You have to write the control register to get them to operate in synchronous mode. I use these devices (and have for some time), and all this is in the datasheet. Either get a core (there are a number of them around) or roll your own FSM taking into account the current mode of the flash device. Cheers PeteSArticle: 113465
PeteS wrote: > lbo_user wrote: > > Sorry, I should have said. This is going to be using synchronous burst > > mode components. > > That makes the interface simpler (once in synchronous mode), but if you > read the datasheet, the devices power up (and end up after reset) in > **asynchronous** mode. You have to write the control register to get > them to operate in synchronous mode. > > I use these devices (and have for some time), and all this is in the > datasheet. > > Either get a core (there are a number of them around) or roll your own > FSM taking into account the current mode of the flash device. > > Cheers > > PeteS Let me correct myself here: The majority of parallel flash devices (NOR), even when listed as synchronous devices, actually start up in asynchronous burst mode. Intel Strata flash (which sets the standard, whether we like it or not, and therefore most other players are 'compatible') start in this mode - asynchronous, burst of [up to] 8. As I noted, read the datasheet for the device type you want to use. Cheers PeteSArticle: 113466
Hi I am working in a design.I am using altera cyclone IC.My design works fine.One problem is whenever it is brought near to LCD it become noisy and stop working.What i have to do.I kept slew rate slow for the output pins and bidirectional low.Can anyone give idea. kumarArticle: 113467
Help!!!!!!!!! Hi, How can I write data into the ddr sdram with Microblaze and the OPB DDR. The SDRAM is 16MX16 and I have only found how can I test this memory. Can anyone tell me something about this????Article: 113468
"John" <seabass950@yahoo.com> wrote in message news:eea0f8b.6@webx.sUN8CHnE... >I am using a digital scope and triggering on rising edge. I do a single >sample and use two cursors to measure the reflection. > > One side of the probe is on the pin, the other side is on ground. > > BTW, 50 ohm source terminator cleaned up the data lines a lot (lowest it > drops to now is 2.9V), but my 25mhz clock signal still has a lot of noise, > since I didn't design my interface board to have a source terminator on > the clock. Hi John, Check your probe is grounded correctly. The 6in wire with a croc clip doesn't cut it at today's rise times. Look for "Sensitivity To The Probe Ground Wire" in this article. http://www.sigcon.com/Pubs/straight/probes.htm This guy has a cool website and shows you how to make your own probe in pictures! (I'm pretty sure I saw him once cycling the other way on the Los Gatos creek trail ["ON YOUR LEFT!"], but that's another story!) http://www.emcesd.com/1ghzprob.htm Also, there's a difference between noise and reflections. For example, if you use your digital scope in infinite persistence mode, noise will make all the traces get thicker vertically as the noise is not correlated to the clock signal you're measuring. On the other hand, reflections are the same for every clock cycle so the traces stay thin. It may help diagnose your problem if you can say which of these is your problem. HTH, Syms.Article: 113469
Thanks Pete, I'm happy with the functionality of the flash, I'm more concerned with the amount of effort needed to write my own controller. The majority of the work looks to be in the program/erase polling state machines. I'm just really short on time and have been looking for faster alternatives to writing my own controller. It's looking more and more like that's the way I'll have to go though. Ta.Article: 113470
"John_H" <newsgroup@johnhandwork.com> wrote in message news:tz5gh.7746$Li6.5593@trndny03... > ashish.dobhal@gmail.com wrote: >> In the presence of numerous styles for designing asynchronous FIFOs, >> how does FPGA synthesis tools infer the FIFO specified in RTL? >> >> Thanks in advance. >> >> Ashish > > I know of no tool that infers FIFOs, async or synchronous. > You must be using very primitive tools. Altera, Xilinx and Synplify (and probably most other major players) certainly do. As to the original question there probably aren't really that many 'styles' as you may think. One time through whatever part of the tool chain it is that takes the raw source code and converts it to something equivalent but easier for the downstream tools to chew on and those supposedly numerous styles likely all pop out looking the same. Remember, no matter how you code it, the functionality of the fifo isn't changing. After all, there are many ways to code just a flip flop and the tools can recognize all of those as well so you could rightly ask the same question about how the tools detect a flip flop. KJArticle: 113471
KJ wrote: > > If someone does have an application that really requires true programmable > flags I'd be interested to hear about it. The environment though is > - Fifo is inside a programmable part. > - That programmable part can be updated in system. I have many examples from telecom side. For example if you have some universal interface card, that has each port configurable to different protocol (for example STM1/4/16). That kind of big change in speed usually needs some changes in fifo limits to get maximum efficiency. If you have for example 8 ports that would need quite many different FPGA images to cover static settings. Also partial reconfiguration in my opinion is little too dififficult way to handle this problem. Of course you can code the static values for each protocol and use mux to select one of them to the fifo comparison logic. But it's easier just to add one register and let the software to handle the values. Also usually maximum efficiency needs some lab testing to find the optimal fifo values. And waiting hours for new fpga after each change in the limits is not fun. I have used programmable flags so many times in lab while debugging different problems in the design, and while trying to understand the dynamics how different limits affect interconnected fifo fystems between chips etc. --KimArticle: 113472
KJ wrote: >>I know of no tool that infers FIFOs, async or synchronous. >> > > You must be using very primitive tools. Altera, Xilinx and Synplify (and > probably most other major players) certainly do. As far as I know they don't. That would be quite an accomplishment. I quickly checked Synplify Premiere 8.6.2 manual and there was nothing about inferring FIFOs. Also Mentor Precicsion 2006a Synthesis Style Guide did not tell about fifo inference. And also Xilinx 8.2i xst manual did not have any text about fifo inferring. Could you point me to the right page in manuals? Completely other thing is lpm_fifo and different DW_*fifo* components. But they must be instantiated directly. Same applies to coregen, altera megafunctions etc. --KimArticle: 113473
glen herrmannsfeldt wrote:
> Koen Van Renterghem wrote:
>
>> Hi,
>>
>> I'm trying to devise an efficient method to generate a ones' complement
>> sum of two 16 bit integers in a single cycle. I'm targeting a Xilinx
>> device and right now I'm using a 32 bit adder. Suppose I want to add x
>> and y :
>
> You need the end-around carry. It is pretty easy with a carry
> lookahead adder to wire the carry out back to the carry in.
>
> (snip)
>
> You should only need a 16 bit adder with carry in/carry out.
>
> How about:
>
> assign {carry,result} = a+b+carry;
>
> The worst case is where the carry propagates 16 bits.
> (Well, the full width.) It never goes farther than that.
>
> -- glen
>
I previously tried this approach, but that resulted in synplify and
xilinx complaining about a combinatorial loop created by connecting the
carry-out to the carry-in of the adder. That is why I started using a
dedicated 16 bit adder to calculate the carry. This carry is then
applied to a second adder.
The statement you suggested will save area, but is there a proper way to
constrain it? Right now the combinatorial loop seems to be ignored in
timing analysis :
<snip>
1 logic loop found and disabled.
----------------------------------------------------------------------
! Warning: The following connections close logic loops, and some paths !
! through these connections may not be analyzed. !
! !
! Signal Driver Load !
! -------------------------------- ---------------- ---------------- !
! csum_2x16_temp<1>_cyo LICE_X46Y82.COUT SLICE_X46Y87.BX !
----------------------------------------------------------------------
<\snip>
Article: 113474Hello Guys, First of all thanks for all of your valuble suggestions.I was able to get the source code (ABEL) for all the PAL's now.Since most of the PAL's were absolute now and for ROHS compliance we are redesigning the board and now we want to replace bulky PAL's around 70 and eight XC3130 series(VHDL) into state of the art FPGA devices. Coming to my first point 1. Can i have a VHDL main module and integrate all the individual .ABL files as it is and achieve the same functionality of all the PAL's within FPGA. (With out converting ABEL to VHDL) 2. Here the board performance (timing of PAL) has to remain the same with high speed FPGA also.Never worked on timing issues till now but heard registering and using flip flop can solve problem any better ideas? (First i am working out on how to get the timing of a PAL from the old board before knowing how to achieve the same timing with in a high speed FPGA ) Sorry for my list of questions and Thanks for being supportive. Naveen lnaveen_2000@yahoo.com lingamaneni.naveen@gmail.com Gabor wrote: > Paul wrote: > > yea... if you've got the actual abel code, not just the "synthesized" > > JED file, you're probably better off rewriting the VHDL. I can't > > imagine that anything that was originally written in ABEL is so > > complicated that it'd take more than a couple hours to rewrite.... if > > i'm not mistaken devices were pretty small back when folks where using > > abel, so it can't feasibly be ALL that much logic to recode. > > > > > > This goes back a long time, but I remember that MachXL software > from AMD used to be able to reconstruct source from a .JED file. > This required a .JED that contained the symbol table (signal names) > to end up with something readable. It unfortunately showed your > equations in sum-of-products just the way it went into the PAL, > not the pre-compiled source. > > If you really have Abel code and not just the JEDEC file, it is my > understanding that Xilinx still supports Abel for anything but top > level code modules. I still have designs using Abel in lower level > modules, but those are supported with the older Foundation 4.1i > tools, so I'm not sure you could use them in newer ISE projects. > > HTH, > Gabor
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