Embedded clocks
in [FPGA]
|
Prev: Cyclone I & II memory fmax
Next: JOP as SOPC component
From: rickman on 12 Aug 2006 16:33 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. > 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. > 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. 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.
From: Frank Buss on 12 Aug 2006 17:27 rickman 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(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Jim Granville on 12 Aug 2006 19:20 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. -jg
From: rickman on 12 Aug 2006 20:58 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.
From: Jacko on 12 Aug 2006 21:42
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 cheers |