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
On Mon, 02 Jan 2017 14:35:36 +0000, Theo Markettos wrote: > Tim Wescott <tim@seemywebsite.com> wrote: >> Seven FF _per digit_. I'm more interested in what was done back in the >> day. Do you know how long the 4-bit CPU has been used? > > The advert for one of the first (Sinclair Black Watch, 1975) describes > the chip: > > <quote> > The chip... > The heart of the Black Watch is a unique IC designed by Sinclair and > Custom -built for them using state -of- the -art technology - integrated > injection logic. This chip of silicon measures only 3 mm x 3 mm and > contains over 2000 transistors.The circuit includes a) reference > oscillator b) divider chain c) decoder circuits d) display inhibit > circuits e) display driving circuits. > The chip is totally designed and manufactured in the UK, and is the > first design to incorporate all circuitry for a digital watch on a > single chip. > > ...and how it works A crystal -controlled reference is used to drive a > chain of 15 binary dividers which reduce the frequency from 32,768 Hz to > 1 Hz.This accurate signal is then counted into units of seconds, > minutes, and hours, and on request the stored information is processed > by the decoders and display drivers to feed the four 7- segment LED > displays. > When the display is not in operation, special power- saving circuits on > the chip reduce current consumption to only a few microamps. > </quote> > > http://www.americanradiohistory.com/Archive-Practical/Wireless/70s/ PW-1976-03.pdf > page 68 (fab was supposed to be Mullard but they pulled out, I think it > was eventually ITT) > > Theo Wow. I think that 2000 transistors is less than half the way to a 4-bit micro, isn't it? So maybe they went that way early on. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 159576
On Mon, 02 Jan 2017 08:07:39 -0700, BobH wrote: > On 12/30/2016 02:03 PM, Tim Wescott wrote: >> Someone on reddit asked about quartz watches, and I told them that one <snip> > It would be possible to implement a state machine that counts in 7 > segment format, but it would be ugly to do, and probably larger than > simple ripple counters feeding into a shared bcd to 7 segment decoder. That answers that question, except for the residual "probably". -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 159577
On 01/02/2017 11:02 AM, Tim Wescott wrote: > On Mon, 02 Jan 2017 08:07:39 -0700, BobH wrote: > >> On 12/30/2016 02:03 PM, Tim Wescott wrote: >>> Someone on reddit asked about quartz watches, and I told them that one > > <snip> > >> It would be possible to implement a state machine that counts in 7 >> segment format, but it would be ugly to do, and probably larger than >> simple ripple counters feeding into a shared bcd to 7 segment decoder. > > That answers that question, except for the residual "probably". > Sprechen Sie Verilog? Give it a try. I have done a lot of state machine design through the years and I can't imagine why a 7 segment counting state machine would not be larger than a simple ripple binary counter. I put the "probably" in because this is usenet, and the probability of getting in a flame war over something like this seems pretty high. If you think about it, the muxed display implementation, with 3 bcd ripple counters sharing one bcd to 7 segment decoder should be way smaller than 4 7 bit counters with complex next state logic. BobHArticle: 159578
On 1/2/2017 9:35 AM, Theo Markettos wrote: > Tim Wescott <tim@seemywebsite.com> wrote: >> Seven FF _per digit_. I'm more interested in what was done back in the >> day. Do you know how long the 4-bit CPU has been used? > > The advert for one of the first (Sinclair Black Watch, 1975) describes the > chip: > > <quote> > The chip... > The heart of the Black Watch is a unique IC designed by Sinclair and Custom > -built for them using state -of- the -art technology - integrated injection > logic. This chip of silicon measures only 3 mm x 3 mm and contains over > 2000 transistors.The circuit includes > a) reference oscillator > b) divider chain > c) decoder circuits > d) display inhibit circuits > e) display driving circuits. > The chip is totally designed and manufactured in the UK, and is > the first design to incorporate all circuitry for a digital watch on a > single chip. > > ...and how it works > A crystal -controlled reference is used to > drive a chain of 15 binary dividers which reduce the frequency from 32,768 > Hz to 1 Hz.This accurate signal is then counted into units of seconds, > minutes, and hours, and on request the stored information is processed by > the decoders and display drivers to feed the four 7- segment LED displays. > When the display is not in operation, special power- saving circuits on the > chip reduce current consumption to only a few microamps. > </quote> > > http://www.americanradiohistory.com/Archive-Practical/Wireless/70s/PW-1976-03.pdf > page 68 > (fab was supposed to be Mullard but they pulled out, I think it was > eventually ITT) Good find! -- Rick CArticle: 159579
On Mon, 02 Jan 2017 14:57:03 -0700, BobH wrote: > On 01/02/2017 11:02 AM, Tim Wescott wrote: >> On Mon, 02 Jan 2017 08:07:39 -0700, BobH wrote: >> >>> On 12/30/2016 02:03 PM, Tim Wescott wrote: >>>> Someone on reddit asked about quartz watches, and I told them that >>>> one >> >> <snip> >> >>> It would be possible to implement a state machine that counts in 7 >>> segment format, but it would be ugly to do, and probably larger than >>> simple ripple counters feeding into a shared bcd to 7 segment decoder. >> >> That answers that question, except for the residual "probably". >> > Sprechen Sie Verilog? Give it a try. > > I have done a lot of state machine design through the years and I can't > imagine why a 7 segment counting state machine would not be larger than > a simple ripple binary counter. I put the "probably" in because this is > usenet, and the probability of getting in a flame war over something > like this seems pretty high. > > If you think about it, the muxed display implementation, with 3 bcd > ripple counters sharing one bcd to 7 segment decoder should be way > smaller than 4 7 bit counters with complex next state logic. I'm really more a systems egghead with solid software (and, oddly, analog circuit) design skills. I don't do much FPGA work, and what I end up doing is nothing to write home about -- I generally know what's possible in pure digital-land, and can work with the real logic guys to make it happen. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159580
On 1/2/2017 6:04 PM, Tim Wescott wrote:
> On Mon, 02 Jan 2017 14:57:03 -0700, BobH wrote:
>
>> On 01/02/2017 11:02 AM, Tim Wescott wrote:
>>> On Mon, 02 Jan 2017 08:07:39 -0700, BobH wrote:
>>>
>>>> On 12/30/2016 02:03 PM, Tim Wescott wrote:
>>>>> Someone on reddit asked about quartz watches, and I told them that
>>>>> one
>>>
>>> <snip>
>>>
>>>> It would be possible to implement a state machine that counts in 7
>>>> segment format, but it would be ugly to do, and probably larger than
>>>> simple ripple counters feeding into a shared bcd to 7 segment decoder.
>>>
>>> That answers that question, except for the residual "probably".
>>>
>> Sprechen Sie Verilog? Give it a try.
>>
>> I have done a lot of state machine design through the years and I can't
>> imagine why a 7 segment counting state machine would not be larger than
>> a simple ripple binary counter. I put the "probably" in because this is
>> usenet, and the probability of getting in a flame war over something
>> like this seems pretty high.
>>
>> If you think about it, the muxed display implementation, with 3 bcd
>> ripple counters sharing one bcd to 7 segment decoder should be way
>> smaller than 4 7 bit counters with complex next state logic.
>
> I'm really more a systems egghead with solid software (and, oddly, analog
> circuit) design skills. I don't do much FPGA work, and what I end up
> doing is nothing to write home about -- I generally know what's possible
> in pure digital-land, and can work with the real logic guys to make it
> happen.
I don't know directly wiring 7 FFs for each digit is a horrible idea.
That would be coded as a FSM by connecting present states with next
states...
SUBTYPE DigitType is unsigned(6 downto 0);
CONSTANT DigitZero : DigitType := "0111111"
CONSTANT DigitOne : DigitType := "0000110"
CONSTANT DigitTwo : DigitType := "1011011"
CONSTANT DigitThree : DigitType := "1001111"
CONSTANT DigitFour : DigitType := "1100110"
CONSTANT DigitFive : DigitType := "1101101"
CONSTANT DigitSix : DigitType := "1111101"
CONSTANT DigitSeven : DigitType := "0000111"
CONSTANT DigitEight : DigitType := "1111111"
CONSTANT DigitNine : DigitType := "1100111"
SIGNAL DigitCur : DigitType;
SIGNAL CntEnable : std_logic;
PROCESS (clk, rst) BEGIN
IF (rst) THEN
DigitCur <= DigitZero ;
ELSIF rising_edge(clk) THEN
IF (CntEnable) THEN
case DigitCur is
when DigitZero => DigitCur <= DigitOne;
when DigitOne => DigitCur <= DigitTwo;
when DigitTwo => DigitCur <= DigitThree;
when DigitThree => DigitCur <= DigitFour;
when DigitFour => DigitCur <= DigitFive;
when DigitFive => DigitCur <= DigitSix;
when DigitSix => DigitCur <= DigitSeven;
when DigitSeven => DigitCur <= DigitEight;
when DigitEight => DigitCur <= DigitNine;
when DigitNine => DigitCur <= DigitZero;
when others => DigitCur <= DigitZero;
end case;
END IF;
END IF;
END PROCESS;
I recall coding a 7 seg to decimal decoder in software once and you
don't even need all the bits as input to determine the next state. I
think I used five. The above code ends up being 7 independent FSM, one
for each bit dependent on what ever ends up being minimal. So I don't
think the logic is very complex. The only real complexity is using 7
FFs instead of 4. A FF has some dozen or more gates and I expect the
PS->NS random logic is less that that for each bit.
For example, the bit for the 'a' segment, the one at the top of the
digit, is only a zero for the 1 and the 4. The preceding states are 0
and 3. To decode those two you can xor segments f and g, then and with
segment c and invert. a_next := not (c and (f_cur xor g_cur)) That's
pretty simple function, one 4 input LUT.
So maybe directly coding the digits with a 7 bit FSM is not such a bad
idea.
--
Rick C
Article: 159581> > Wow. I think that 2000 transistors is less than half the way to a 4-bit > micro, isn't it? So maybe they went that way early on. > I'm sure they must've used a custom circuit initially. The text about the "display inhibit" circuit reminded me that the original digital watches were luminous (not LCD) and you had to push a button to display the time, in order to save the battery. It would be an interesting homework problem to design a digital watch chip with the fewest 2-input gates. Gated clocks, glitches, and latches all allowed.Article: 159582
Kevin Neilson wrote: >> Wow. I think that 2000 transistors is less than half the way to a 4-bit >> micro, isn't it? So maybe they went that way early on. >> > I'm sure they must've used a custom circuit initially. The text about the "display inhibit" circuit reminded me that the original digital watches were luminous (not LCD) and you had to push a button to display the time, in order to save the battery. > > It would be an interesting homework problem to design a digital watch chip with the fewest 2-input gates. Gated clocks, glitches, and latches all allowed. Check out this article comparing the first Pulsar digital watch to the new Apple watch: https://dealspotr.com/article/apple-watch-has-come-a-long-way-since-the-first-digital-watch It seems that this model (produced only in small quantity) did not have a custom chip (article quotes 25 chips in the watch). It had a button to illuminate the display and two magnet-activated switches to set the time (hours and minutes). Modern digital alarm clocks still use the same clunky Hour and Minute buttons to set time, which is very frustrating when you want to move the time back by one minute or one hour. A friend of mine worked at Fairchild not long after the first digital watches came out. He told me that they made chips for digital clocks that included a 4-bit micro. Chips for AC plug-in clocks used 60 Hz from the power mains for the time base, with a self-calibrated (against the power mains frequency) internal oscillator for battery-backup mode. -- GaborArticle: 159583
GaborSzakacs <gabor@alacron.com> wrote: > It seems that this model (produced only in small quantity) did not have > a custom chip (article quotes 25 chips in the watch). It had a button > to illuminate the display and two magnet-activated switches to set the > time (hours and minutes). Modern digital alarm clocks still use the > same clunky Hour and Minute buttons to set time, which is very > frustrating when you want to move the time back by one minute or one > hour. There's some pictures of the mechanism here: http://www.timetrafficker.com/private/pulsar-p1-25-chip-module/ What's interesting is the modern-looking SMD construction, with gold tracks on a ceramic substrate. The LEDs use discrete bond wires but all the chips are in 12/14 pin ceramic packages, of roughly MSOP size. Each of the 25 chips is lettered. There are 5 As, 5 Ks, 5 Gs, 3 Cs, and one each of BDEFHIL - looking at the layout it's possible to infer something about their function. I wonder if they're 74- or more likely 4000-series in custom packages? TheoArticle: 159584
Le mercredi 30 mai 2012 16:50:12 UTC-4, jonpry a =C3=A9crit=C2=A0: > Hi all, >=20 > I have a Spartan-6 LX45 board with a whole bunch of lvds going in > and out at a rate of 780mbps. After running out of pins I was forced > to put two lvds receiving pairs into a different bank from the rest of > the bus. To make matters worse this bank has an active MCB. All of > the tx/rx lvds is synchronous with a clock I have inside the fpga so > both transmit and receive are handled through the BUFPLL method > suggested in XAPP1064. Receive channels are using the differential > phase detector mode of IDELAY2 and ISERDES2. >=20 > The bank with the MCB presents a unique challenge because the MCB > makes use of both BUFPLL resources available along that edge of the > device. On the bright side I am able to run the memory interface at > the same 780mbps potentially allowing me to use the same BUFPLL > technique used on other edges of the device. The problem is that the > MCB requires the BUFPLL to be run with DIVIDE=3D2 essentially causing > the fabric side of the ISERDES2 to run at 390mhz! >=20 > In the XAPP1064 source code I found the following note relating to > the instantiation of ISERDES2: >=20 > DATA_WIDTH =3D> 6, -- SERDES word width. This should match the > setting is BUFPLL >=20 > I wonder what exactly "should" means. Say that I have BUFPLL with > divide=3D2 and ISERDES with width=3D6. What is really going to happen? > Looking at figure 3-1 on page 80 of UG381. It looks to me as though it > would work fine. A bitslip machine would be able to line of which of > the 3 strobes was actually the correct one.Article: 159585
Le mercredi 30 mai 2012 16:50:12 UTC-4, jonpry a =C3=A9crit=C2=A0: > Hi all, >=20 > I have a Spartan-6 LX45 board with a whole bunch of lvds going in > and out at a rate of 780mbps. After running out of pins I was forced > to put two lvds receiving pairs into a different bank from the rest of > the bus. To make matters worse this bank has an active MCB. All of > the tx/rx lvds is synchronous with a clock I have inside the fpga so > both transmit and receive are handled through the BUFPLL method > suggested in XAPP1064. Receive channels are using the differential > phase detector mode of IDELAY2 and ISERDES2. >=20 > The bank with the MCB presents a unique challenge because the MCB > makes use of both BUFPLL resources available along that edge of the > device. On the bright side I am able to run the memory interface at > the same 780mbps potentially allowing me to use the same BUFPLL > technique used on other edges of the device. The problem is that the > MCB requires the BUFPLL to be run with DIVIDE=3D2 essentially causing > the fabric side of the ISERDES2 to run at 390mhz! >=20 > In the XAPP1064 source code I found the following note relating to > the instantiation of ISERDES2: >=20 > DATA_WIDTH =3D> 6, -- SERDES word width. This should match the > setting is BUFPLL >=20 > I wonder what exactly "should" means. Say that I have BUFPLL with > divide=3D2 and ISERDES with width=3D6. What is really going to happen? > Looking at figure 3-1 on page 80 of UG381. It looks to me as though it > would work fine. A bitslip machine would be able to line of which of > the 3 strobes was actually the correct one.Article: 159586
Dear All, please help with VHDL, i connected MPU6050 to my FPGA board. I used www.eewiki.com tutorial, can anybody exlpain me how to read burst data 16 bits from 2 registers or 6 regsiters ? by only one operation ? I use https://eewiki.net/pages/viewpage.action?pageId=11042934#SPItoI2CBridge(VHDL)-CodeDownload but reads only 1 byte . any suggestion would be appreciated/Article: 159587
On 1/5/2017 6:36 AM, abirov@gmail.com wrote: > Dear All, please help with VHDL, i connected MPU6050 to my FPGA board. > > I used www.eewiki.com tutorial, can anybody exlpain me how to read burst data 16 bits from 2 registers or 6 regsiters ? by only one operation ? > > I use https://eewiki.net/pages/viewpage.action?pageId=11042934#SPItoI2CBridge(VHDL)-CodeDownload but reads only 1 byte . > > any suggestion would be appreciated/ The eewiki page is about connecting an SPI master to an I2C slave through an FPGA. Is that what you are doing? The intro says the bridge will read 8 bit I2C registers. It doesn't say anything about reading multiple registers in one SPI operation. In fact, the SPI Mode section says the SPI interface must receive a 33 bit command to transfer a single 8 bit byte from the I2C slave to the SPI master. I think if you want to do large transfers in one operation you will need to substantially change the SPI interface in the FPGA and possibly the rest of the design as well. -- Rick CArticle: 159588
On Thursday, January 5, 2017 at 6:33:36 PM UTC+6, rickman wrote: > On 1/5/2017 6:36 AM, abirov@gmail.com wrote: > > Dear All, please help with VHDL, i connected MPU6050 to my FPGA board. > > > > I used www.eewiki.com tutorial, can anybody exlpain me how to read burst data 16 bits from 2 registers or 6 regsiters ? by only one operation ? > > > > I use https://eewiki.net/pages/viewpage.action?pageId=11042934#SPItoI2CBridge(VHDL)-CodeDownload but reads only 1 byte . > > > > any suggestion would be appreciated/ > > The eewiki page is about connecting an SPI master to an I2C slave > through an FPGA. Is that what you are doing? > > The intro says the bridge will read 8 bit I2C registers. It doesn't say > anything about reading multiple registers in one SPI operation. In > fact, the SPI Mode section says the SPI interface must receive a 33 bit > command to transfer a single 8 bit byte from the I2C slave to the SPI > master. > > I think if you want to do large transfers in one operation you will need > to substantially change the SPI interface in the FPGA and possibly the > rest of the design as well. > > -- > > Rick C Yes it is, i try to change i2c_to_spi conversion to i2c_to_PWM for servo, so I need 16 bit word from 2 register.Article: 159589
On Thursday, January 5, 2017 at 6:33:36 PM UTC+6, rickman wrote: > On 1/5/2017 6:36 AM, abirov@gmail.com wrote: > > Dear All, please help with VHDL, i connected MPU6050 to my FPGA board. > > > > I used www.eewiki.com tutorial, can anybody exlpain me how to read burst data 16 bits from 2 registers or 6 regsiters ? by only one operation ? > > > > I use https://eewiki.net/pages/viewpage.action?pageId=11042934#SPItoI2CBridge(VHDL)-CodeDownload but reads only 1 byte . > > > > any suggestion would be appreciated/ > > The eewiki page is about connecting an SPI master to an I2C slave > through an FPGA. Is that what you are doing? > > The intro says the bridge will read 8 bit I2C registers. It doesn't say > anything about reading multiple registers in one SPI operation. In > fact, the SPI Mode section says the SPI interface must receive a 33 bit > command to transfer a single 8 bit byte from the I2C slave to the SPI > master. > > I think if you want to do large transfers in one operation you will need > to substantially change the SPI interface in the FPGA and possibly the > rest of the design as well. > > -- > > Rick C I made register map file where is just puts device address, register address and value to make write or read operation and it write some value to initial device and reads results, but only 8 bits . I think somewhere in I2C master or user logic file need to make edition. But my knowledge of VHDL is limited and cannot develop it more ))).Article: 159590
On 1/5/2017 8:25 AM, abirov@gmail.com wrote: > On Thursday, January 5, 2017 at 6:33:36 PM UTC+6, rickman wrote: >> >> The eewiki page is about connecting an SPI master to an I2C slave >> through an FPGA. Is that what you are doing? >> >> The intro says the bridge will read 8 bit I2C registers. It doesn't say >> anything about reading multiple registers in one SPI operation. In >> fact, the SPI Mode section says the SPI interface must receive a 33 bit >> command to transfer a single 8 bit byte from the I2C slave to the SPI >> master. >> >> I think if you want to do large transfers in one operation you will need >> to substantially change the SPI interface in the FPGA and possibly the >> rest of the design as well. > > I made register map file where is just puts device address, register address and value to make write or read operation and it write some value to initial device and reads results, but only 8 bits . > I think somewhere in I2C master or user logic file need to make edition. But my knowledge of VHDL is limited and cannot develop it more ))). VHDL isn't the issue until you understand how to use the I2C bus. Your other post seemed to indicate you are using an I2C master to control a servo with a PWM signal. Is that correct? I am no expert on I2C, but I believe it is not hard to send two bytes in one command. You need to study the I2C bus spec. If the entire I2C to PWM design is in your FPGA it should not be hard to design it to not glitch as the two 8 bit registers are updated separately. So there are two ways to do this. -- Rick CArticle: 159591
> > There's some pictures of the mechanism here: > http://www.timetrafficker.com/private/pulsar-p1-25-chip-module/ > I was wondering what the glass tubes underneath the circuit board were--they look like the inside of reed relays. Then I realized that's exactly what they are. They're the switches used for setting the time, activated with an external magnet.Article: 159592
torsdag 5. januar 2017 12.36.19 UTC+1 skrev abi...@gmail.com f=C3=B8lgende: > Dear All, please help with VHDL, i connected MPU6050 to my FPGA board. >=20 > I used www.eewiki.com tutorial, can anybody exlpain me how to read burst= data 16 bits from 2 registers or 6 regsiters ? by only one operation ? >=20 > I use https://eewiki.net/pages/viewpage.action?pageId=3D11042934#SPItoI2C= Bridge(VHDL)-CodeDownload but reads only 1 byte . >=20 > any suggestion would be appreciated/ I learned a lot of I2C from the I2C reference design for picoblaze embedded= microcontroller in Xilinx. Picoblaze has a complete tool chain from assemb= ler to VHDL, and the code for the mcu can be downloaded to chip with JTAG t= o shorten development cycle.Article: 159593
I modified user logic from eewiki.com if someone need please use code below :
WHEN read_data => ------------------------------------------------
message0 (15 downto 0) <= "0000000000000000";
i2c_busy_prev <= i2c_busy;
IF (i2c_busy_prev = '0' AND i2c_busy = '1') THEN
i2c_busy_cnt := i2c_busy_cnt + 1;
END IF;
CASE i2c_busy_cnt IS
WHEN 0 =>
i2c_ena <= '1';
i2c_addr <= data_in(6 downto 0);
i2c_rw <= '0';
i2c_data_wr <= data_in(14 downto 7);
WHEN 1 =>
i2c_ena <= '1';
i2c_rw <= data_in(15);
i2c_data_wr <= data_in(23 downto 16);
WHEN 2 =>
i2c_ena <= '1';
IF (i2c_busy = '0') THEN
message(15 downto 8) <= i2c_data_rd;
END IF;
WHEN 3 =>
i2c_ena <= '0';
IF (i2c_busy = '0') THEN
message(7 downto 0) <= i2c_data_rd;
message(16) <= i2c_ack_err;
i2c_busy_cnt := 0;
state <= combine;
END IF;
WHEN OTHERS => NULL;
Article: 159594Hi, I am doing a small exercise to learn verilog on FPGAs trying to create a FSK31 (ham-radio digital mode) from a FPGA using DDS. The boards I have use either a Spartan6 (XC6SLX9) or an Cyclon IV (EP4CE10). The problem to create a digital signal for even the lowest ham-bands (137 Khz) using DDS, the I/O pin of the lowest bit needs to switch at 35.6 Mhz (if using a nice 8bit DDS). For higher bands, the problem is even worse, or I need to reduce the resolution of the DDS My question: I have looked at the documents by altera or xilinx that describe switching-speed of I/O pins of their chips, but -from what I understand it all- FPGAs seams to have special I/O driving hardware to drive very-high speed interfaces and this does make it all a bit "muddy". Can somebody explain in (relative) simple and "beginners-lingo" how I/O of an FPGA works really works, what kinds of I/O ports there are, and how I can know (or change) what is the typical maximum switching-speed of an I/O port on a spartan6 or a Cyclone-IV. Cheerio! KristoffArticle: 159595
On 1/15/2017 6:43 PM, kristoff wrote: > Hi, > > > > I am doing a small exercise to learn verilog on FPGAs trying to create a > FSK31 (ham-radio digital mode) from a FPGA using DDS. First of all, do you mean PSK31 or FSK31? I see both are used, but PSK31 is much more common. Are you looking to generate an audio signal that you can feed into the mic input of a transmitter? Or are you looking to produce the RF signal directly? > The boards I have use either a Spartan6 (XC6SLX9) or an Cyclon IV > (EP4CE10). > > > The problem to create a digital signal for even the lowest ham-bands > (137 Khz) using DDS, the I/O pin of the lowest bit needs to switch at > 35.6 Mhz (if using a nice 8bit DDS). For higher bands, the problem is > even worse, or I need to reduce the resolution of the DDS I have no idea what you mean by this. A DDS typically creates sine waves although there are times a square wave is appropriate. Or is this an all digital process? Are you talking about the digital output which will drive a DAC? > My question: > I have looked at the documents by altera or xilinx that describe > switching-speed of I/O pins of their chips, but -from what I understand > it all- FPGAs seams to have special I/O driving hardware to drive > very-high speed interfaces and this does make it all a bit "muddy". What part is muddy? > Can somebody explain in (relative) simple and "beginners-lingo" how I/O > of an FPGA works really works, what kinds of I/O ports there are, and > how I can know (or change) what is the typical maximum switching-speed > of an I/O port on a spartan6 or a Cyclone-IV. Better would be if you can explain what you intend to do with the output from the FPGA? Is this a digital output or an analog output? -- Rick CArticle: 159596
kristoff wrote: > I have looked at the documents by altera or xilinx that describe > switching-speed of I/O pins of their chips, but -from what I understand > it all- FPGAs seams to have special I/O driving hardware to drive > very-high speed interfaces and this does make it all a bit "muddy". > In general, you would have the I/O pad driven by a FF clocked at some system frequency. So, you could only change to output state at one of those clock edges. At least on Xilinx, it is possible to run an output directly from some signal from the FPGA fabric. This is generally frowned upon as the delay between internal and I/O can be less well defined. Xilinx does have SERDES components that can run much faster than the rest of the chip, and some of them can get up to the GHz clock range. These can serialize a number of parallel bits running at some lower rate into a serial stream at much higher rates. These FPGAs have a limited number of these SERDES components. You instantiate them using a tool provided by Xilinx. > > Can somebody explain in (relative) simple and "beginners-lingo" how I/O > of an FPGA works really works, what kinds of I/O ports there are, and > how I can know (or change) what is the typical maximum switching-speed > of an I/O port on a spartan6 or a Cyclone-IV. I only know Xilinx. Each I/O pad has a receiver and a transmitter that can be set up as tri-state. There are also FFs that can be selected into the input and output paths. You can define in the HDL how you want the I/O pad to operate. Also, the Xilinx parts have controllable delays that be used to adjust for timing issues between external parts and the FPGA. The outputs are VERY fast, you can probably run a 300 MHz clock on the output FFs and thus get 150 MHz square waves out. You also have selectable voltage standards on these I/Os, generally selected in banks and powered by different voltages. So, you can have an FPGA with 3.3 V signals on one side, and 1.8 V signals on the other. This is all set up in the tools, with a constraint file that defines the I/O standard for each pin. JonArticle: 159597
Jon Elson wrote: > > Xilinx does have SERDES components that can run much faster than the rest of > the chip, and some of them can get up to the GHz clock range. These can > serialize a number of parallel bits running at some lower rate into a serial > stream at much higher rates. The maximum switching rate on a pin is very dependent on the IO standard selected. To get the GHz rates you need to use a differential output standard like LVDS. Single-ended like LVCMOS defaults to using a slew-rate limited driver, which will further reduce the effective switching speed. Make sure you set the slew rate to FAST on the high-speed pin if it is running single-ended. For Spartan-6 you also need to be aware that the device is not homogenous. Typically these parts have "top and bottom" banks of I/O and "left and right" banks of I/O. Some banks have more drive capability on single-ended standards, but don't have the capability to do differential output. Check your board to make sure that the I/O bank type you need is actually brought out to a connector. Xilinx documentation is somewhat fragmented. You don't get it all in one "datasheet" like you would on simpler devices. They have a data sheet with electrical characteristics, and a lot of "user guides" describing functionality like I/O, configuration, and clocking. As far as I can remember, they generally don't publish maximum switching rate numbers on all I/O types. You'd need to run IBIS simulations to get most of them. LVDS maximum bit rates may be specified in the family overview document, because they will be the highest rates possible using general I/O. If you have a Spartan-6 LXT device (with gigabit transceivers) you also have the option to use those to achieve much higher switching rates, but the interface insn't so simple. If you decide to use the Xilinx board rather than Altera, you can get a lot more insight going on the Xilinx forums, where even the Xilinx employees are available to answer questions. Good luck on your project, it sounds interesting. -- GaborArticle: 159598
On Sun, 15 Jan 2017 22:17:53 -0500, rickman wrote: > On 1/15/2017 6:43 PM, kristoff wrote: >> Hi, >> >> >> >> I am doing a small exercise to learn verilog on FPGAs trying to create >> a FSK31 (ham-radio digital mode) from a FPGA using DDS. > > First of all, do you mean PSK31 or FSK31? I see both are used, but > PSK31 is much more common. > > Are you looking to generate an audio signal that you can feed into the > mic input of a transmitter? Or are you looking to produce the RF signal > directly? > > >> The boards I have use either a Spartan6 (XC6SLX9) or an Cyclon IV >> (EP4CE10). >> >> >> The problem to create a digital signal for even the lowest ham-bands >> (137 Khz) using DDS, the I/O pin of the lowest bit needs to switch at >> 35.6 Mhz (if using a nice 8bit DDS). For higher bands, the problem is >> even worse, or I need to reduce the resolution of the DDS > > I have no idea what you mean by this. A DDS typically creates sine > waves although there are times a square wave is appropriate. Or is this > an all digital process? Are you talking about the digital output which > will drive a DAC? > > >> My question: >> I have looked at the documents by altera or xilinx that describe >> switching-speed of I/O pins of their chips, but -from what I understand >> it all- FPGAs seams to have special I/O driving hardware to drive >> very-high speed interfaces and this does make it all a bit "muddy". > > What part is muddy? > > >> Can somebody explain in (relative) simple and "beginners-lingo" how I/O >> of an FPGA works really works, what kinds of I/O ports there are, and >> how I can know (or change) what is the typical maximum switching-speed >> of an I/O port on a spartan6 or a Cyclone-IV. > > Better would be if you can explain what you intend to do with the output > from the FPGA? Is this a digital output or an analog output? If he's doing what I think he's doing he wants to produce RF directly from a DAC that is connected to the FPGA. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.comArticle: 159599
On Mon, 16 Jan 2017 00:43:25 +0100, kristoff wrote: > Hi, > > > > I am doing a small exercise to learn verilog on FPGAs trying to create a > FSK31 (ham-radio digital mode) from a FPGA using DDS. > > > The boards I have use either a Spartan6 (XC6SLX9) or an Cyclon IV > (EP4CE10). > > > The problem to create a digital signal for even the lowest ham-bands > (137 Khz) using DDS, the I/O pin of the lowest bit needs to switch at > 35.6 Mhz (if using a nice 8bit DDS). For higher bands, the problem is > even worse, or I need to reduce the resolution of the DDS How are you arriving at that number? In a world where perfect reconstruction filters exist, you can run the output frequency all the way up to half of the clock frequency. If you want to make the reconstruction filtering much easier you'd limit the output to something like Fs/4 -- and 548kHz is a hell of a lot less than 35.6MHz. This article should help to clarify your thinking: http://wescottdesign.com/articles/Sampling/sampling.pdf As for your question about I/O rates: probably up to hundreds of MHz, but it somewhat depends on your abilities. If you don't want to spread your output spectrum from the DDS you may want to make a stable clock source external of the FPGA and use that both to drive the DAC's sample clock and the FPGA. At least the last time I checked (which, granted, was 20 years ago), internal FPGA circuitry was too noisy to use as sampling clocks in communications applications. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
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