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
> Not really, it is just simpler to say that I'm not going to go anywhere near code that can potentially change any of the outputs
> if wait request is active. As an example, take a look at your code below where you've had to sprinkle the 'if av_waitrequest =
> '0' throughout the code to make sure you don't change states at the 'wrong' time (i.e. when av_waitrequest is active). Where
> problems can come up is when you miss one of those 'if av_waitrequest = '0' statements. Depending on just where exactly you
> missed putting it in is is where it can be a rather subtle problem to debug.
Agree on the save side, but...
>
> Now consider if you had simply put the 'if av_waitrequest = '0' statement around your entire case statement (with it understood
> that outside that
I cannot do this. This case statement is combinatoric. It would introduce
a latch for next_state. The reason to split up the state machine in
a combinatoric next state logic and the clocked part is to react
'one cycle earlier' with state machine output registers depending
on next_state. You can code this also with a single case in a clock
process. However, than you have to code your output registers on the
transitions (in the if part), which gets a little bit more confusing.
>>
>> What about this version (sc_* signals are my internal master signals)
>>
>> that case is the next state logic and combinatorial:
the process containing this case statement is:
process(state, sc_rd, sc_wr, av_waitrequest)
begin
next_state <= state;
>>
>> case state is
>>
>> when idl =>
>> if sc_rd='1' then
>> if av_waitrequest='0' then
>> next_state <= rd;
>> else
>> next_state <= rdw;
>> end if;
>> elsif sc_wr='1' then
>> if av_waitrequest='0' then
>> next_state <= wr;
>> else
>> next_state <= wrw;
>> end if;
>> end if;
>>
>> when rdw =>
>> if av_waitrequest='0' then
>> next_state <= rd;
>> end if;
>>
>
>> when rd =>
>> next_state <= idl;
> --- Are you sure you always want to go to idl? This would probably cause an error if the avalon outputs were active in this
> state.
No problem as next_state goes to rd only when av_waitrequest is '0'.
Perhaps 'rd' is a missleading state name. The input data is registered
when next_state is 'rd'. So state is 'rd' when the input data is registered.
>
> Whether it works or not for you would take more analysis, I'll just say that
For a complete picture you can look at the whole thing at:
http://www.opencores.org/cvsweb.cgi/~checkout~/jop/vhdl/scio/sc2avalon.vhd
>>> You might try looking at incorporating the above mentioned template and avoid the Avalon violation. What I've also found in
>>> debugging other's code
>>
>> Then I get an additional cycle latency. That's what I want to avoid.
>
> Not on the Avalon bus, maybe for getting stuff into the template but even that is a handshake. I've even used Avalon within
> components to transfer
Ok, than not at the Avalon bus directly but as you sayed 'getting stuff
into the template'. That's the same for me (in my case).
If my master has a (internal) read request and I have to forward it
to Avalon in a clocked process (as you do with your template)
I will loose one cycle. Ok in the interface and not in the bus.
Still a lost cycle ;-)
> data between rather complicated processes just because it is a clean data transfer interface and still have no problem
> transferring data on every clock cycle when it is available. I'm not familiar enough with your code, but I suspect that it can be
> done in your case as well.
You can do it when your template 'controls' the master logic but not
the other way round.
>> And then it goes on with slaves with fixed wait states. Why?
>> If do not provide a waitrequest in a slave that needs wait
>> states you can get into troubles when you specify it wrong
>> at component genration.
>
> No, PTF files let you state that there are a fixed number of wait states and not have an explicit waitrequest on the slave.
I meant when you assume n wait states in your VHDL code, but
did a mistake in the PTF file and specified less wait states.
This erro cannot happen when you generate the waitrequest within
your VHDL code.
>>
>> Or does the Avalon switch fabric, when registered, take this
>> information into account for the waitrequest of the master?
>
> It does.
That's a reason to go with fix wait states!
Or a bus specification that counts down the number of
wait states ;-)
BTW: Did you take a look into the SimpCon idea?
Dreaming a little bit: Would be cool to write an
open-source system generator (like SOPC builder) for
it. Including your suggestion of an open and documented
specification file format.
>
>> Could be for the SRAM component. Should look into the
>> generated VHDL code (or in a simulation)...
>>
> I'd suggest looking at the system.ptf file for your design.
It's still in ns, which makes sense.
Martin
>> Again, one more cycle latency ;-)
> Again, nope not if done correctly.
I think we finally agreed, did we?
Cheers,
Martin
Article: 106401rickman wrote: > I don't see one wire as being any simpler than a UART. One wire is > just bit async rather than byte async. You still need a timer to time > the bits. I, and maybe Jim, assumed that you have a more powerful master and multiple slaves, which you scan. Then it is easier and cheaper to use just some SMD resistor and capacitor than an oscillator, which is reliable with the one wire bus, if you provide one exact clock from a master. > Yeah, I have thought about I2C, but it would have to run at High Speed > to work properly due to the addressing overhead. SPI would work too, > but would use all four pins leaving us no spares. A UART interface > could use two wires, one for transmit and one for receive. The word > size can be application specific with dedicated bits for discrete > signals. Most importantly, I think it will be the smallest in a CPLD. How fast do you need to communicate? Maybe you can do all with a CPLD, but with the HCS08 you have a tested 100 kbps I2C bus integrated (and up to 1 mbps with reduced bus loading) and it is easier to program a microcontroller than a FPGA (I've programmed it in an other project with a C compiler). http://www.freescale.com/files/microcontrollers/doc/data_sheet/MC9S08GB60.pdf The 32 kbyte Flash single unit price is $8.81, which is more than twice as expensive as the 64 macro cell CPLD XC9572XL-10VQG64C, but you don't need any more external components, if you need A/D converters and the precision of the internal oscillator is good enough for your application. But after taking a look at the CPLDs from Xilinx, maybe this is a good idea, too. I didn't know that they have integrated Flash, so you need only some external RC component for the clock. Is a CPLD big enough for a CPU core? This would be the ideal combination: high-speed tasks implemented in VHDL and complex tasks implemented with an integrated CPU. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 106402
flo schrieb: > Hi everyone, > I'm trying to deal with readback and scrubbing into a XC2V1500 FPGA. > > I've got a problem identifying the Major Adress and the Minor Adress > when I'm doing a readback. > I read documents (XAPP138 and XAPP151) but nothing works with virtexII. > I know the frame length and the number of frame because it is in the > bitstream but nothing about the number of frame in each minor adress > depending on the major address and the blockk type... > > Does anyone know how to determine it? > > Thanks a lot. > > florent this information is available in some files in the \xilinx\ dirs but you cant access them. the easiest is to run bitgen with debug option and then look at the file, it will write out each frame separatly so you can gather the information you need anttiArticle: 106403
Todd Fleming schrieb: > Ralf Hildebrandt wrote: > > I strongly guess that the flipflop has normal and inverted output. > > Therefore you get the inversion for free (for the cost of these flipflops). > > And furthermore it seems to be, that the pure combinational solutions > > are slightly to complex to fit into 8 LUTs (the inversion is too much to > > fit). > > > > Ralf > > I don't see any reference to an inverted output on the flipflops in the > Spartan 3 data sheet. From looking at the slice diagram in the DS and > the schematic for ADSU8 in the library guide, it looks like the LUTs > should be able to absorb the inverter on b. > > Todd any signal inversion at LUT inputs are of couse "absorbed" so it should no make any difference if signals are inverted or not. AnttiArticle: 106404
aijazbaig1@gmail.com wrote: > I know that VHDL - 93 allows one to completely do away with components > but incase of VHDL - 87 , are we allowed to reference an entity > directly as you did. No, but any tool without -93 support is too old for serious use. > Normally M1 can be called an instant of the component in the "normal" > case when we instantiate components but now as you haven't declared any > components then what does M1 stand for. I might instance the entity more than once. > As far as I know we cannot have > instances of entities (or can we??). All instances are of entities. > Secondly with regards to using the full mapping, do we have to place > the target signals on the right hand side of the "=>" operator inside > the port map clause brackets? Does this matter at all? Yes, yes. -- Mike TreselerArticle: 106405
PeteS wrote: > rickman wrote: >> jai.dhar@gmail.com wrote: >>> Hey guys, >>> >>> I'm having trouble getting started with my first clock-domain crossing >>> task. I need to take in 2 signals; a 2.048M clock and associated data >>> stream, and transfer it to a 50M stream that outputs a single-pulse >>> clock and the captured data. What structure/resources can I use for >>> this? >> With a 50 MHz reference clock and adequate setup/hold times, you should >> be able to do the entire design in that domain and never use the 2 MHz >> clock as a true clock inside the FPGA. First, all signals will need to >> be clocked through two FFs to minimize metastability. Unfortunately >> this adds a 50 MHz clock period of jitter to any relative measurement. >> With a 25:1 clock rate difference this should not be too much of a >> concern, but keep it in mind as you perform a timing analysis. >> >> Once all signals are sampled into the chip's clock domain you can do a >> simple edge detection on the incoming 2.048 MHz clock signal to >> generate a single 50 MHz clock wide, 2.048 MHz enable signal. This >> will be delayed or the data will be delayed by 50 MHz clock intervals >> to put your sampling point in the center of your data setup and hold >> period if it is at all critical. >> >> After that you just use the 2.048 MHz enable signal to gate the >> handling of the data. > > The task isn't that clear, but a 2.048MHz clock makes me suspect there > is a serial data stream clocked at 2.048MHz that then is to be retimed > onto a 50MHz clock. In this case, there are a number of solutions, but > a more definitive statement is required. 2.048MHz is, of course, a very > common clock in PCM type applications as used in voice processing. > > I *think* the OP is asking how to retime (maintaining the framing) a > serial data stream from one clock domain to another. > > Cheers > > PeteS > I'd question whether ALL input signals need synchronisation FFs into the 50MHz domain. The 2.048MHz clock does, indeed. However, assuming the input data already had adequate setup time from the 2.048MHz clock, it will be safe to sample it against the synchronised (hence, delayed) version of that clock.Article: 106406
rickman wrote: > Jim Granville wrote: > >>rickman wrote: >><snip> >> >>>If I am going to require a time reference at the receiver the simplest >>>scheme I know of is just async serial data with a start and a stop bit. >> >>This is not quite the simplest. >> >>It imposes clock tolerance requirements, and is half duplex, so the >>Transmit has to generate it's own clock. > > > But if I have an oscillator, I have a clock available. That is my > point. RS-232 has very loose requirements for a clock. An RC may not > be good enough, but it doesn't take much. anything better than RC, has starting time issues, so usually runs all the time, and that has power penalties. > >>If you want to ease that, you can do something like the LIN bus, which >>gives a auto-baud pre-amble, but that is getting complex for CPLDs. > > > Way too complex. I am looking at a very small package and I may be > limited to 64 logic cells. In fact I don't know that I can make this > work in such a small part. The problem is that one end of the link has > to be built into a cable housing where the signals are fanned out > again. I don't need a lot of IO, but I expect it will take more than > 64 logic cells. > > > >>> No point in using Manchester encoding if I am transferring the data >>>over a wire just a few inches long. >> >>Many TV remote's use manchester, and they do that to allow the use of RC >>clocks, and straight from battery operation. >> >>If you want the simplest scheme, in a CPLD, use one-wire, because that >>is duplex, and does not need to generate a TX clock, just a Tx time slot >>( which can be monostable derived ). > > > I don't see one wire as being any simpler than a UART. One wire is > just bit async rather than byte async. You still need a timer to time > the bits. build them both, and count the macrocells :) UARTs need (commonly) /16 resettable counter on RX, and a /16 non resetable counter on TX, plus the byte buffers in both directions. So that's at least 8 macrocells running higher than the bit-rate, plus appx 4 more do do the framing, vs 3-4 for PWM bus. PWM Osc is gated-monostable type at 4x bit rate - so power is lower. A 3 bit Gray counter handles RxSample, TxWindow, and Sync detect Simulating all this is not that easy, on today's tools, which are designed for a master-clock approach. >>If you can get up to 2 wires, then i2c & variants are a widely used >>standard, and it does not take too much CPLD resource. > > > Yeah, I have thought about I2C, but it would have to run at High Speed > to work properly due to the addressing overhead. CPLDs have no problems with speed, but the host speed may be a stumbling block. Philips talked about 3.4MHz i2c, but nothing seems to have hit the streets. I see they now have a FM+ spec, which is high drive i2c, at 1MBd, also well within CPLD's reach. i2c Address info can be compile-time-coded into CPLDs, to save pins and macrocell resource. > SPI would work too, but would use all four pins leaving us no spares. SPI can work with 3 wires, if that helps. > A UART interface could use two wires, one for transmit and one for receive. > The word > size can be application specific with dedicated bits for discrete > signals. Most importantly, I think it will be the smallest in a CPLD. How many IO's do you need, on how many addresses ? Do they need dataDirection register control, and read-back, or are simpler fixed OUT and IN acceptable ? 64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts. -jgArticle: 106407
Jim Granville wrote: > anything better than RC, has starting time issues, so usually runs > all the time, and that has power penalties. RC is not even an oscillator without other componets so it really is not a solution. I can get an oscillator that runs on 1 mA of current, costs under $0.50 and has plenty of accuracy to do any of the above protocols. So async serial is ok. One in and one out. > > I don't see one wire as being any simpler than a UART. One wire is > > just bit async rather than byte async. You still need a timer to time > > the bits. > > build them both, and count the macrocells :) > > UARTs need (commonly) /16 resettable counter on RX, and a /16 non > resetable counter on TX, plus the byte buffers in both directions. > > So that's at least 8 macrocells running higher than the bit-rate, > plus appx 4 more do do the framing, vs 3-4 for PWM bus. A PWM bit level signal still has to do all the higher level stuff of counting the bits in a word etc. So if there is an savings, it would be very little. > PWM Osc is gated-monostable type at 4x bit rate - so power is lower. > A 3 bit Gray counter handles RxSample, TxWindow, and Sync detect > > Simulating all this is not that easy, on today's tools, which are > designed for a master-clock approach. > > > CPLDs have no problems with speed, but the host speed may be a stumbling > block. Philips talked about 3.4MHz i2c, but nothing seems to have hit > the streets. I see they now have a FM+ spec, which is high drive i2c, > at 1MBd, also well within CPLD's reach. The host would be another CPLD. The "host" has to take in two SPI running near 100 kHz and four discrete signals. I have no info on how the SPI data is framed. I2C is done in bytes, but my understanding is that SPI has no defined protocol, it really is a non-standard standard. I will have to get more info on how the SPI busses are being used before I can decide if this will even work. > > SPI would work too, but would use all four pins leaving us no spares. > > SPI can work with 3 wires, if that helps. I could put an address on the SPI bus like I2C does it. I can't recall at the moment why I felt it would need a fourth pin. I think because of flagging which of the two SPI ports was running at that moment. But that can be encoded in the data stream so I guess it could leave a pin free. > > A UART interface could use two wires, one for transmit and one for receive. > > > The word > > size can be application specific with dedicated bits for discrete > > signals. Most importantly, I think it will be the smallest in a CPLD. > > How many IO's do you need, on how many addresses ? I don't understand. Do you mean the discrete signals? > Do they need dataDirection register control, and read-back, or > are simpler fixed OUT and IN acceptable ? No, just four outputs. They are triggers with timing information, but I don't know how precise they need to be. > 64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts. You did not account for the two SPI ports that are being multiplexed. Without more info on the protocol on the SPI ports, I can't count FFs. But each one will need a buffer since the link will have to run much faster than either of the two SPI ports. Also I don't even know if this will work since SPI is full duplex, IIRC. As you shift out data read data is coming back, right? Or is it still half duplex with the read data and write data never happening at the same time? I would not be able to buffer words and do full duplex. That sounds incompatible to me.Article: 106408
hi designing an open and free specification IC (OFSIC) and am wondering of the possibility of a bytecode for programming a moderate array, and loading the in and out for custom functionization on a runtime basis. must be a bytecode, can have a literal fetch and other things, does not have to handle jumping as the cpu will do that, this is just a synchronized program and eval parrallel bytecode stream. for convienice lets limit it to 64k unique programming bits, but less may be possible. cheesrArticle: 106409
you get state change or no state change to represent a bit, therfore some time limit has to be placed on the stream to get data flow. a delta sigma stream can be filtered at any fast rate and represent many levels the data rate will be limited by various factors. a virtual grey code could be set up with no -max to +max when in the middle two states, either up or down is possible, one option says clock 0, and one says clock 1 when on the outer two states, then eventually move into one of the middle states. as you can not loop peak to peak cheersArticle: 106410
rickman wrote: > Jim Granville wrote: > >>anything better than RC, has starting time issues, so usually runs >>all the time, and that has power penalties. > > > RC is not even an oscillator without other componets so it really is > not a solution. I can get an oscillator that runs on 1 mA of current, > costs under $0.50 and has plenty of accuracy to do any of the above > protocols. So async serial is ok. One in and one out. RC osc would use the CPLD - not sure what 'other components' you mean. If you are happy with 1mA and 50c, then that's fine. I see in my notes, Core ICC figures of ~20uA @ 15KHz for a CPLD RC osc, at a cost of a few cents. ( and appx 50uA at 1MHz ) > >>>I don't see one wire as being any simpler than a UART. One wire is >>>just bit async rather than byte async. You still need a timer to time >>>the bits. >> >>build them both, and count the macrocells :) >> >>UARTs need (commonly) /16 resettable counter on RX, and a /16 non >>resetable counter on TX, plus the byte buffers in both directions. >> >>So that's at least 8 macrocells running higher than the bit-rate, >>plus appx 4 more do do the framing, vs 3-4 for PWM bus. > > > A PWM bit level signal still has to do all the higher level stuff of > counting the bits in a word etc. So if there is an savings, it would > be very little. Again, it depends on your yardstick. When you are working with 32 Macrocell CPLDs, as I do often, a saving of 8 macrocells can be very important. <snip> >>64 Macrocells sounds plenty, could even manage this in 32 Macrocell parts. > > > You did not account for the two SPI ports that are being multiplexed. > Without more info on the protocol on the SPI ports, I can't count FFs. I thought this was a multi-slave plus master problem - you seem to be talking only about the master above - what are the slaves ? > But each one will need a buffer since the link will have to run much > faster than either of the two SPI ports. Also I don't even know if > this will work since SPI is full duplex, IIRC. As you shift out data > read data is coming back, right? Or is it still half duplex with the > read data and write data never happening at the same time? I would not > be able to buffer words and do full duplex. That sounds incompatible > to me. SPI works like the simplest 8 bit shift registers, so it is duplex capable. Most SPI memories, work in half-duplex - they read the address info, while floating SerialOUT, and then ignore SerialIN, while driving serial out (if doing a read). If you have to slave to two separate SPI streams, that you have little control over, that could get complex very quickly. -jgArticle: 106411
Excellent replies, thank you all so much. Let me clear up the application, my apologies for being vague. As you may have guessed, it's telecom/PCM/T1/E1 application. There's a TX and an RX stream... the TX stream (w.r.t. to the T1 interface - TX = data flowing from the FPGA to the line-side) has a 2.048M clock and a TSD signal, and RX has the same clock and a RSD signal into the FPGA. What I would like to do is for the RX side, take the incoming RSD stream, and translate it to 1-bit wide 50M pulses. So I would end up with 2 new signals, a 'bit' signal and another 'rsd' signal - the bit signal pulses high for 1-bit in 50M domain when data is avaialble on the 'rsd' line, in 50M. TX works similarly. I hope this clarifies the applciation. I really like the initial method suggested - just using 50M to sample the the 2.048M clock and do edge detection on it. It seems very simple. .. Actually, I forgot to clarify one aspect. The FPGA is itself generating the 2.048M clock (divided from a 8M192) as well as a framing pulse. That's easy enough to do of course... does this add any complications if the FPGA is generating the pulses? I would think it makes it easier... David R Brooks wrote: > PeteS wrote: > > rickman wrote: > >> jai.dhar@gmail.com wrote: > >>> Hey guys, > >>> > >>> I'm having trouble getting started with my first clock-domain crossing > >>> task. I need to take in 2 signals; a 2.048M clock and associated data > >>> stream, and transfer it to a 50M stream that outputs a single-pulse > >>> clock and the captured data. What structure/resources can I use for > >>> this? > >> With a 50 MHz reference clock and adequate setup/hold times, you should > >> be able to do the entire design in that domain and never use the 2 MHz > >> clock as a true clock inside the FPGA. First, all signals will need to > >> be clocked through two FFs to minimize metastability. Unfortunately > >> this adds a 50 MHz clock period of jitter to any relative measurement. > >> With a 25:1 clock rate difference this should not be too much of a > >> concern, but keep it in mind as you perform a timing analysis. > >> > >> Once all signals are sampled into the chip's clock domain you can do a > >> simple edge detection on the incoming 2.048 MHz clock signal to > >> generate a single 50 MHz clock wide, 2.048 MHz enable signal. This > >> will be delayed or the data will be delayed by 50 MHz clock intervals > >> to put your sampling point in the center of your data setup and hold > >> period if it is at all critical. > >> > >> After that you just use the 2.048 MHz enable signal to gate the > >> handling of the data. > > > > The task isn't that clear, but a 2.048MHz clock makes me suspect there > > is a serial data stream clocked at 2.048MHz that then is to be retimed > > onto a 50MHz clock. In this case, there are a number of solutions, but > > a more definitive statement is required. 2.048MHz is, of course, a very > > common clock in PCM type applications as used in voice processing. > > > > I *think* the OP is asking how to retime (maintaining the framing) a > > serial data stream from one clock domain to another. > > > > Cheers > > > > PeteS > > > I'd question whether ALL input signals need synchronisation FFs into the > 50MHz domain. The 2.048MHz clock does, indeed. However, assuming the > input data already had adequate setup time from the 2.048MHz clock, it > will be safe to sample it against the synchronised (hence, delayed) > version of that clock.Article: 106412
I've reviewed the docs briefly but didn't find this information. I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to use all the available I/O pins to drive LEDs (that's 104 of them), and do something silly like turn 'em all on at once, will I exceed the maximum current draw of the chip and let out the magic smoke? The eight red LED's on the board are driven directly from the I/O pins through 390 ohm resistors. I am planning on attaching a green LED to each of the 96 I/O pins exposed on the connectors through 390 ohm resistors. Thx, -NevoArticle: 106413
One chip of Virtex 4,SX35F668,is used in my PCB board,When the board is first assembled,the FPGA could performance very well,but about a month later,the FPGA could not work correctly even download with the same bitstream file once worked OK. I check the operate current of the total board,the current is about 0.5A lower than normal(5V input voltage),After the review every detail parameters of each ICs on the board,the static resistor of 2.5V is much higher than before(approximate 800ohm now but approximate 10ohm before),the 2.5V is only provided to FPGA`s Vccaux and two banks`s Vcco.because the Vccaux is provided to DCM,so I write a Program to test the 8 DCMs in Virtex 4 SX35,the test result is that:every time I turn on the power and load the same bitstream file to FPGA through JTAG,the output of the 8 DCMs is not the same!Sometimes,2 or 3 DCMs`s output is not correct,and the DCM lock signal keep low,the worst condition is 5 of 8 DCMs`s output is not correct, and the correct DCM and incorrect DCM is not fixed during each time. could anyone give me some advice to solve the problem?Article: 106414
Do your homework: Build one such interface, then measure the supply voltage and the voltage on either side of the 390 Ohm resistor. Use simple math to clculate the current, and also the power dissipation inside the chip, for this one instant. Then multiply the power by 96. I am quite sure that the current will be below 1 A, and thus no problem. But you might think about the on-chip power dissipation. All you need is a multimeter and high-school math. Peter Alfke ======================== Nevo wrote: > I've reviewed the docs briefly but didn't find this information. > > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to > use all the available I/O pins to drive LEDs (that's 104 of them), and do > something silly like turn 'em all on at once, will I exceed the maximum > current draw of the chip and let out the magic smoke? > > The eight red LED's on the board are driven directly from the I/O pins > through 390 ohm resistors. > > I am planning on attaching a green LED to each of the 96 I/O pins exposed on > the connectors through 390 ohm resistors. > > Thx, > > -NevoArticle: 106415
Peter, Where did the 1A maximum come from? That's the figure I couldn't find in my quick look at the datasheet. Thanks! -Nevo "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1155440396.057616.75560@b28g2000cwb.googlegroups.com... > Do your homework: > Build one such interface, then measure the supply voltage and the > voltage on either side of the 390 Ohm resistor. Use simple math to > clculate the current, and also the power dissipation inside the chip, > for this one instant. Then multiply the power by 96. > I am quite sure that the current will be below 1 A, and thus no > problem. But you might think about the on-chip power dissipation. > All you need is a multimeter and high-school math. > Peter Alfke > ======================== > Nevo wrote: >> I've reviewed the docs briefly but didn't find this information. >> >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were >> to >> use all the available I/O pins to drive LEDs (that's 104 of them), and do >> something silly like turn 'em all on at once, will I exceed the maximum >> current draw of the chip and let out the magic smoke? >> >> The eight red LED's on the board are driven directly from the I/O pins >> through 390 ohm resistors. >> >> I am planning on attaching a green LED to each of the 96 I/O pins exposed >> on >> the connectors through 390 ohm resistors. >> >> Thx, >> >> -Nevo >Article: 106416
There is no max Icc spec. But I find 1 A acceptable, since we often see 3 W power dissipation... I think there is a (very conservative) spec that wants to keep the current per pin below 10 mA (I think 20 to 30 mA is fine), and it looks like all that is not really your problem. Peter Alfke, Xilinx Applications (from home) =================================== Nevo wrote: > Peter, > > Where did the 1A maximum come from? That's the figure I couldn't find in my > quick look at the datasheet. > > Thanks! > > -Nevo > > "Peter Alfke" <alfke@sbcglobal.net> wrote in message > news:1155440396.057616.75560@b28g2000cwb.googlegroups.com... > > Do your homework: > > Build one such interface, then measure the supply voltage and the > > voltage on either side of the 390 Ohm resistor. Use simple math to > > clculate the current, and also the power dissipation inside the chip, > > for this one instant. Then multiply the power by 96. > > I am quite sure that the current will be below 1 A, and thus no > > problem. But you might think about the on-chip power dissipation. > > All you need is a multimeter and high-school math. > > Peter Alfke > > ======================== > > Nevo wrote: > >> I've reviewed the docs briefly but didn't find this information. > >> > >> I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were > >> to > >> use all the available I/O pins to drive LEDs (that's 104 of them), and do > >> something silly like turn 'em all on at once, will I exceed the maximum > >> current draw of the chip and let out the magic smoke? > >> > >> The eight red LED's on the board are driven directly from the I/O pins > >> through 390 ohm resistors. > >> > >> I am planning on attaching a green LED to each of the 96 I/O pins exposed > >> on > >> the connectors through 390 ohm resistors. > >> > >> Thx, > >> > >> -Nevo > >Article: 106417
Peter .. he WAS doing his homework, and forced to ask the list because XILINX continues to refuse to specify the part completely. Your "process" for determining this does NOT provide the answer for other than ONE part, at ONE voltage, at ONE temperature. The process does NOT provide any clue about how the next 1 million parts will perform, nor does it provide a defective screening limit to return high current parts that are well outside of specification (which XILINX refuses to provide). Your answer to this poster, isn't any better than the XILINX answer to mine last winter. John Peter Alfke wrote: > Do your homework: > Build one such interface, then measure the supply voltage and the > voltage on either side of the 390 Ohm resistor. Use simple math to > clculate the current, and also the power dissipation inside the chip, > for this one instant. Then multiply the power by 96. > I am quite sure that the current will be below 1 A, and thus no > problem. But you might think about the on-chip power dissipation. > All you need is a multimeter and high-school math. > Peter Alfke > ======================== > Nevo wrote: > > I've reviewed the docs briefly but didn't find this information. > > > > I'm playing with a XC3S400 in a 256 BGA on the Digilent board. If I were to > > use all the available I/O pins to drive LEDs (that's 104 of them), and do > > something silly like turn 'em all on at once, will I exceed the maximum > > current draw of the chip and let out the magic smoke? > > > > The eight red LED's on the board are driven directly from the I/O pins > > through 390 ohm resistors. > > > > I am planning on attaching a green LED to each of the 96 I/O pins exposed on > > the connectors through 390 ohm resistors. > > > > Thx, > > > > -NevoArticle: 106418
That's a tough call, as Xilinx doesn't provide an internal (no IO) self test bitstream for their FPGAs making in-field, on-board, testing of the parts impossible. Not specificed for OEM to test parts before placing on a board either. It's a total nightmare to qualify these parts, on or off board, in a lot of respects. John Borry.Wang@gmail.com wrote: > One chip of Virtex 4,SX35F668,is used in my PCB board,When the board is > first assembled,the FPGA could performance very well,but about a month > later,the FPGA could not work correctly even download with the same > bitstream file once worked OK. I check the operate current of the total > board,the current is about 0.5A lower than normal(5V input > voltage),After the review every detail parameters of each ICs on the > board,the static resistor of 2.5V is much higher than > before(approximate 800ohm now but approximate 10ohm before),the 2.5V > is only provided to FPGA`s Vccaux and two banks`s Vcco.because the > Vccaux is provided to DCM,so I write a Program to test the 8 DCMs in > Virtex 4 SX35,the test result is that:every time I turn on the power > and load the same bitstream file to FPGA through JTAG,the output of the > 8 DCMs is not the same!Sometimes,2 or 3 DCMs`s output is not > correct,and the DCM lock signal keep low,the worst condition is 5 of 8 > DCMs`s output is not correct, and the correct DCM and incorrect DCM is > not fixed during each time. > > could anyone give me some advice to solve the problem?Article: 106419
fpga_toys@yahoo.com wrote: > Peter .. he WAS doing his homework, and forced to ask the list because > XILINX continues to refuse to specify the part completely. Your > "process" for determining this does NOT provide the answer for other > than ONE part, at ONE voltage, at ONE temperature. The process does NOT > provide any clue about how the next 1 million parts will perform, nor > does it provide a defective screening limit to return high current > parts that are well outside of specification (which XILINX refuses to > provide). > > Your answer to this poster, isn't any better than the XILINX answer to > mine last winter. To give this a reference point, here is an example from over the fence, of a Philips data sheet : http://www.standardics.philips.com/products/pca/pdf/pca9506.pdf Notice they specify: Maximum power Maximum current per pin Idd Max Gnd Max Total Iol, recommended and Vol Mins, for Vcc and Temp limits This device is a LED driver, and yes, that is the level of spec a designer could reasonably expect to find in a data sheet, when designing for LED drive usage. -jgArticle: 106420
rickman wrote:
> Ok, I thought this would fail and it did. This sequence is the same
> bit pattern as before, with one edge detected differently from jitter.
01 01 10 10
> 0001101110010000
?00?10?11?01?00? <- ? indicates sample can go either way
> 0001100110010000
01\__/10 10
ambiguous
1001
<snip>
Thank you, rickman. Your persistence has shown me that a 3x solution
probably cannot unambiguously decode a Manchester encoded signal. I
would hope that running through the simulations would have pointed this
out quickly and clearly. For the 3x case, the unambiguous pairs
determined by the runs of three or more constant values decode fine in
the first case but cannot guarantee a decode in the second, at least if
the run of 4 is discounted for the moment; I feel ignoring it is
necessary for the general case since phases will slip between the
sampler and the transmit clock.
In the second example you gave above that has the one key bit sampling
the other side of the edge, the pairs (also working backward from the
end of the pattern) end up with a gap that I cannot determine the
appropriate bit.
Despite my early confidence, you appear correct.
My background dealt a lot with the CMI (Complementary Mark Inversion)
encoding for 140 Mbit/s telecom data. This format requires a rising
edge at mid bit for a zero (always a 01 pair of half bits) while a one
had no mid-bit transition at all (either a 00 or 11 half bit pair).
Transitions from a one to a one would switch polarity, guaranteeing at
least one transition per bit period where falling edges *only* occur at
the edge of the bit period. This encoding scheme appears to be easier
to decode than the Manchester at lower oversampling rates.
I don't easily find a solution to the Manchester decoder that will work
simply for a very wide frequency range (such as 10x) while handling
small multiplier values without confusion. The limits for widest half
pulse versus narrowest full pulse sample periods aren't so easy to
define when the ideal multiplier is unknown.
I appreciate the "fun" in delving deeper into this subject than I
normally would go. If you want something "like" Manchester but with
better behavior, perhaps CMI is an encoding to consider.
- John Handwork
Article: 106421Wow, this spanned a long thread. Martin Schoeberl wrote: > What helps is to know in advance (one or two cycles) when the result > will be available. That's the trick with the SimpCon interface. That approach is common internally in real cores, but adds a lot of complication while it's an open question how many Avalon application could benefit from it. > There is not a single ack or waitrequest signal, but a counter that > will say how many cycles it will take to provide the result. In this > case I can restart the pipeline earlier. AFAIR, Avalon _does_ support slaves with fixed number of latency cycles, but an SDRAM controller by nature won't be fixed cycles. > Another point is, in my opinion, the wrong role who has to hold data > for more than one cycle. This is true for several busses (e.g. also > Wishbone). For these busses the master has to hold address and write > data till the slave is ready. This is a result from the backplane > bus thinking. In an SoC the slave can easily register those signals > when needed longer and the master can continue. When happens then when you issue another request to a slave which hasn't finished processing the first? Any queue will be finite and eventually you'd have to deal with stalling anyway. Any issue is that there are generally many more slaves than masters so it makes sense to move the complication to the master. ... > Wishbone and Avalon specify just a single cycle data valid. Again, simplify the slave (and the interconnect) and burden the master. Avalon is IMO the best balance between complexity, performance and features in all the (few) interconnect I've seen yet (I haven't seen SimpCon yet). In particular I found Wishbone severely lacking for my needs. Avalon is proprietary though, so I roll my own portable implementation inspired by Avalon with just the features I needed: - all reads are pipelined with variable latency (accept of request is distinct from delivery of data, thus inherently supporting multiple outstanding requests) - multi master support - burst support (actually not implemented yet, but not that hard) It's nearly as trivial as Wishbone, though offers much higher performance. Latency is entirely up to the slave which can deliver data as soon as the cycle after the request was posted. (Though, arriving at this simplicity took a few false starts). > Are there any other data available on that. I did not find many > comments in this group on experiences with Cyclone I and II. Looks > like the CII was more optimized for cost than speed. Yes, waiting > for III ;-) The only mention of Cyclone III I've seen outside this newsgroups was some mentioning in passing on EEtimes that suggested SIII and CIII were expected this year. I just used Cyclone III as a generic term for whatever the next Altera low-cost part is. Regards, TommyArticle: 106422
Antti Lukats wrote: >>> as very simple example for avalon master-slave type of peripherals there >>> is on free avalon IP core for SD-card support the core can be found >>> at some russian forum and later it was also added to the user ip >>> section of the microtronix forums. >> Any link handy for this example? >> > http://forum.niosforum.com/forum/index.php?showtopic=4430 "Sorry, the link that brought you to this page seems to be out of date or broken." I can see other postings just fine, though. Another reference? TommyArticle: 106423
"Tommy Thorn" <foobar@nowhere.void> schrieb im Newsbeitrag news:44DEB88F.50805@nowhere.void... > Antti Lukats wrote: >>>> as very simple example for avalon master-slave type of peripherals >>>> there >>>> is on free avalon IP core for SD-card support the core can be found >>>> at some russian forum and later it was also added to the user ip >>>> section of the microtronix forums. >>> Any link handy for this example? >>> >> http://forum.niosforum.com/forum/index.php?showtopic=4430 > > "Sorry, the link that brought you to this page seems to be out of date or > broken." > > I can see other postings just fine, though. Another reference? > > Tommy Tommy the link works, but you may have to register at the niosforum in any case the sd card ip is one of the lasting postings at "post your ip" section at niosforum i dont have an link ready where the download would be accessible without registration sure I can re-upload it somewhere:) anttiArticle: 106424
Phil wrote:
> I am not sure what you mean by the PS/2 UART core. Do I have to write
> this core myself or can i get it from somewhere? My knowledge of this
> stuff is extremely limited. In addition, I was suggested to use 2
> GPIOs to take the input of the clock and the input of hte keyboard
> signal. If i tried to implement it this way, do u have any idea what i
> should do?
Check out the user guide for the Spartan-3E starter kit. It's a very
concise description of what the PS/2 keyboard interface is.
It seems you assume you can decode the clock and data directly in
software. You can, but it would require polling them in an expensive
loop. Not quite so expensive if you hook up the keyboard clock to
generate an interrupt, but still.
Radarman suggested to decode the clock and data in RTL and present the
decoded data in a io register. Raising an interrupt upon new data is a
good idea.
Here's a snippet from when I was playing with it:
module main(....
.....
filter #(25_000_000,90_000) filter_inst1(clk25MHz, ps2_kclk,
ps2_kclk_filtered, ps2_kclk_stb);
filter #(25_000_000,90_000) filter_inst2(clk25MHz, ps2_kdata,
ps2_kdata_filtered, ps2_kdata_stb);
/* All the following could just a easy (and much cheaper) be done
in sw. */
always @(posedge clk25MHz) begin
/* Capture on every negedge if already started or if a start bit
is seen */
if (ps2_kclk_stb && ~ps2_kclk_filtered && (kdata_count != 0 ||
~ps2_kdata_filtered)) begin
/* <start: 0> <b0> <b1> ... <b7> <parity> <stop: 1> */
kdata <= {ps2_kdata_filtered, kdata[8:1]};
kdata_count <= kdata_count + 1;
if (kdata_count == 10) begin
kdata_count <= 0;
/* At this point we have kdata = <party> <b7> <b6> .. <b0> */
if (ps2_kdata_filtered & ^kdata[8:0]) begin
/* We got a good scan code */
scancode <= kdata[7:0];
keylift <= 0;
if (~keylift) begin
if (kdata[7:0] != 8'hF0)
{led_r, s7_1_r, s7_0_r} <= {kdata[7:0], led_r, s7_1_r};
case (kdata[7:0])
'hF0: keylift <= 1;
'h45: {digit1,digit0} <= {digit0, 4'd0};
'h16: {digit1,digit0} <= {digit0, 4'd1};
'h1E: {digit1,digit0} <= {digit0, 4'd2};
'h26: {digit1,digit0} <= {digit0, 4'd3};
'h25: {digit1,digit0} <= {digit0, 4'd4};
'h2E: {digit1,digit0} <= {digit0, 4'd5};
'h36: {digit1,digit0} <= {digit0, 4'd6};
'h3D: {digit1,digit0} <= {digit0, 4'd7};
'h3E: {digit1,digit0} <= {digit0, 4'd8};
'h46: {digit1,digit0} <= {digit0, 4'd9};
'h1C: {digit1,digit0} <= {digit0, 4'd10};
'h32: {digit1,digit0} <= {digit0, 4'd11};
'h21: {digit1,digit0} <= {digit0, 4'd12};
'h23: {digit1,digit0} <= {digit0, 4'd13};
'h24: {digit1,digit0} <= {digit0, 4'd14};
'h2B: {digit1,digit0} <= {digit0, 4'd15};
endcase // case(kdata)
end
end
end
end
end
endmodule
For good meassure:
module filter(input clock,
input in,
output reg out, // out a filtered version of in
output reg strobe); // true for one cycle synchronous
with a change
parameter freq = 25_000_000; // 25MHz
parameter limit = 50_000; // 50kHz
parameter dur = freq / limit;
parameter N = 14; // INV: 2**N > dur;
reg [N:0] countdown;
reg in_, in__;
always @(posedge clock) begin
strobe <= 0;
in_ <= in; // Metastability go away
in__ <= in_; // please
if (in__ == out)
countdown <= dur - 1; // Saw an edge, start counting
else if (~countdown[N])
countdown <= countdown - 1;
else begin
out <= ~out; // Ok, this edge lived long enough
strobe <= 1;
end
end
endmodule
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