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
Hello, I am trying to run SD-SDI interface on Cyclone II using Altera SDI core. Since Cyclone II has no transceivers - soft-transceivers are used, so I use PLL to generate 135MHz, 337.5MHz, 337.5MHz+90deg clocks from 27MHz oscillator. The core is provided with these clocks, but when I connect the SDI signal to SDI input, only RXCLK, which is 135MHz, and RX_DATA_VALID, which is about RXCLK/5, are provided on output pins. I am sure I feed the real and correct SDI signal, but no other outputs are working. Its strange that RX_DATA_VALID comes up, even RX_DATA is always 0. Did I miss something? I don't know how to debug core when all clocks are OK, input seems like OK, but nothing goes out. P.S. RX_RST and EN_SYNC_SWITCH are always tied to 0. Thank You.Article: 150801
I have priority Queue vhdl code and I want to give this Code a
(Character,freq)
shown at the end of the code ,so that I will have a huffman encoded out
put.
pls help ,thanks
package commonConstants is
constant wordSize: integer := 23;
end package commonConstants;
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use work.commonConstants.all;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity Huffman_Algo is
Port ( clk, reset : in std_logic;
insert, delete : in std_logic;
key, value : in std_logic_vector(wordSize-1 downto 0);
smallValue : out std_logic_vector(wordSize-1 downto 0);
busy, empty, full : out std_logic
);
end Huffman_Algo;
architecture arch1 of Huffman_Algo is
constant rowSize: integer := 23;
type pqElement is record
dp: std_logic;
key: std_logic_vector(wordSize-1 downto 0);
value: std_logic_vector(wordSize-1 downto 0);
end record pqElement;
type rowTyp is array(0 to rowSize-1) of pqElement;
signal top, bot: rowTyp;
type state_type is (ready, inserting, deleting);
signal state: state_type;
begin
process(clk) begin
if clk'event and clk = '1' then
if reset = '1' then
for i in 0 to rowSize-1 loop
top(i).dp <= '0'; bot(i).dp <= '0';
end loop;
state <= ready;
elsif state = ready and insert = '1' then
if top(rowSize-1).dp /= '1' then
for i in 1 to rowSize-1 loop
top(i) <= top(i-1);
end loop;
top(0) <= ('1',key,value);
state <= inserting;
end if;
elsif state = ready and delete = '1' then
if bot(0).dp /= '0' then
for i in 0 to rowSize-2 loop
bot(i) <= bot(i+1);
end loop;
bot(rowSize-1).dp <= '0'; state <= deleting;
end if;
elsif state = inserting or state = deleting then
for i in 0 to rowSize-1 loop
if top(i).dp = '1' and
(top(i).key < bot(i).key or bot(i).dp = '0') then
bot(i) <= top(i); top(i) <= bot(i);
end if;
end loop;
state <= ready;
end if;
end if;
end process;
smallValue <= bot(0).value when bot(0).dp = '1' else
(smallValue' range => '0');
empty <= not bot(0).dp;
full <= top(rowSize-1).dp;
busy <= '1' when state /= ready else '0';
end arch1;
---Characters with frequency
(s,32)
(a,17)
(u,9)
(h,9)
(f,18)
(e,42)
(m,10)
(y,5)
(z,1)
(.,2)
(q,3)
(n,21)
(o,23)
(t,13)
(l,13)
(r,26)
(space,56)
(c,16)
(i,15)
(d,14)
(g,7)
(b,4)
(p,3)
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 150802On 2/11/2011 8:38 PM, Hal Murray wrote: > In article<3292f4d0-26e9-44fe-9b09-2904190036e0@w36g2000vbi.googlegroups.com>, > KJ<kkjennings@sbcglobal.net> writes: >> On Feb 10, 5:59=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal >> Murray) wrote: >>> In article<311b9cbf-426b-4e86-8d8a-1ad293d4b...@8g2000prt.googlegroups.c= >> om>, >>> >>> =A0KJ<kkjenni...@sbcglobal.net> writes: >>>> On Feb 10, 12:01=3DA0pm, Alessandro Basili<alessandro.bas...@cern.ch> >>>> wrote: >>> >>>>>> KJ >>> >>>>> Concerning the dual clock fifo: >>>>> to which domain should belong the "fifo full" and "fifo empty" status >>>>> registers? >>> >>>> Fifos can only become full when written to. =A0Therefore, 'fifo full' >>>> should be computed in the 'write clock' domain. >>>> Fifos can only become empty when read from. =A0Therefore, 'fifo empty' >>>> should be computed in the 'read clock' domain. >>> >>> Right, but they become un-full on the read clock. >>> >> >> Generally speaking, becoming 'un-full' on a dual clock fifo is not a >> concern. Writing to a full fifo is not recoverable, data has been >> lost. At best a status bit gets set reporting this error. For that >> reason, the *setting* of 'fifo full' status must always be accurate >> and must therefore always be synchronous to the write clock. >> >> The resetting of 'fifo full' (i.e. fifo becoming 'un-full') which >> happens during a fifo read is less important to be accurate on any >> particular clock cycle. All that is incurred is latency before the >> write side is able to again start writing which can be designed for by >> sizing the fifo appropriately to account for the latency in >> transferring the read request from the read clock domain over into the >> write clock domain. Assuming that the fifo is sized to account for >> the known latency, then no error occurs. >> >> The same logic applies to having to always be accurate about setting >> 'fifo empty' relative to the read clock but being allowed to be later >> about resetting (i.e. becoming 'un-empty') when a write occurs. >> >> Kevin Jennings > > The key idea is that full and empty aren't really synchronous > with either read or write clock so you can't just feed them > into a FSM and expect things to work if the tools don't complain. > I am sorry but I don't understand why not. An FSM can always poll for the status bit, fifo-full on the write side and fifo-empty on the read side, and go at full speed until the bit is set. This will require a poll at each write/read operation. Am I missing something? > If you are smart enough, you can think about the issue and use > the going-full path without the delay of a synchronizer as long as > you are careful about the un-full path. > Which delay of a synchronizer? As far as I understood there's crossing over the two clock domains, data are moved in a memory with one clock and retrieved with another one. > One solution in some cases is to use an almost-full flag. You > can run it through the classic synchronizer and the delay won't > kill you. If it's not almost-full, you can write at > full speed, knowing it won't go full before the signal > gets through the synchronizer. If it is almost-full, you can > go slow enough to let the full flag get through a synchronizer. > What is the classic synchronizer? What do you mean by "slow enough"? I apologize for my stupid questions but I may have missed your point. AlArticle: 150803
Yet another FPGA Dev Board question. Is there an Altera Cyclone Based FPGA Dev Board that allows programming via USB cable? This is not to be confused with the USB blaster setup. I need one that has the programming hardware embedded and ease of use - so that I can program using just an usb cable connected between my laptop and a usb socket on the board. Does this exist?Article: 150804
> Is there an Altera Cyclone Based FPGA Dev Board that allows programming > via USB cable? > This is not to be confused with the USB blaster setup. I need one that > has the programming hardware embedded and ease of use - so that I can > program using just an usb cable connected between my laptop and a usb > socket on the board. Without knowing more about your budget and requirements, here are a couple: http://www.knjn.com/FPGA-FX2.html http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=56&No=364 JoelArticle: 150805
Alessandro Basili <alessandro.basili@cern.ch> wrote: (snip, someone wrote) >>>>> Fifos can only become full when written to. =A0Therefore, 'fifo full' >>>>> should be computed in the 'write clock' domain. >>>>> Fifos can only become empty when read from. =A0Therefore, 'fifo empty' >>>>> should be computed in the 'read clock' domain. (snip) >>> Generally speaking, becoming 'un-full' on a dual clock fifo is not a >>> concern. Writing to a full fifo is not recoverable, data has been >>> lost. At best a status bit gets set reporting this error. For that >>> reason, the *setting* of 'fifo full' status must always be accurate >>> and must therefore always be synchronous to the write clock. >> The key idea is that full and empty aren't really synchronous >> with either read or write clock so you can't just feed them >> into a FSM and expect things to work if the tools don't complain. > I am sorry but I don't understand why not. An FSM can always poll for > the status bit, fifo-full on the write side and fifo-empty on the read > side, and go at full speed until the bit is set. This will require a > poll at each write/read operation. Am I missing something? When you cross a clock domain, there is always the possibility that the signal will be just slightly before, or slightly after the clock, and the system has to work either way. The usual FIFO uses a dual-port RAM, two gray code counters (or binary counters and gray code conversion). Gray code allows the count to cross the clock domain, such that either the new or previous value is seen on the other side. >> If you are smart enough, you can think about the issue and use >> the going-full path without the delay of a synchronizer as long as >> you are careful about the un-full path. Things get interesting when the read and write clock edges are close together. Depending on the timing, the empty/full logic might see the count off by one. That has to be in the direction of less full or less empty, rather than the other way around. > Which delay of a synchronizer? As far as I understood there's crossing > over the two clock domains, data are moved in a memory with one clock > and retrieved with another one. Yes. The counters have to cross the clock domain, such that the full/empty logic works. (snip) -- glenArticle: 150806
On 02/13/2011 06:54 PM, aldorus wrote: > Yet another FPGA Dev Board question. > Is there an Altera Cyclone Based FPGA Dev Board that allows programming > via USB cable? > This is not to be confused with the USB blaster setup. I need one that > has the programming hardware embedded and ease of use - so that I can > program using just an usb cable connected between my laptop and a usb > socket on the board. > > Does this exist? Most of the Terasic boards (http://www.terasic.com.tw/) do exactly this (by having USB-Blaster compatible circuitry on the board itself.) -hpaArticle: 150807
> Most of the Terasic boards (http://www.terasic.com.tw/) do exactly this > (by having USB-Blaster compatible circuitry on the board itself.) > > -hpa Terasic seems to be the consensus. I am going to get a DE1. Thanks alotArticle: 150808
Hi, I have a 4 yr old xilinx spartan-3 starter kit which came with a parallel port JTAG programming cable. My desktop with the parallel port died recently. As desktops/laptops no longer ship with parallel port so i am looking for a USB programming cable. However the one available from Xilinx is for 225$ which is pretty steep for me. Any suggestions for alternative cheaper USB JTAG programming cable for xilinx boards ? Regards,Article: 150809
On Feb 14, 2:28=A0pm, jack <postbox4j...@gmail.com> wrote: > Hi, > > I have a 4 yr old xilinx spartan-3 starter kit which came with a > parallel port JTAG programming cable. My desktop with the parallel > port died recently. As desktops/laptops no longer ship with parallel > port so i am looking for a USB programming cable. However the one > available from Xilinx is for 225$ which is pretty steep for me. > > Any suggestions for alternative cheaper USB JTAG programming cable for > xilinx boards ? > > Regards, You could use the $39 USB JTAG cable from Digilent, I'm thinking of getting one. It isn't supported by Impact, but Digilent supplies their own Adept software for it. LeonArticle: 150810
You could try ebay I picked one up for about $30 a while back. Another alternative is to build your own as I think Xilinx provide the schematics now. I believe some people on the net have done this. Enterpoint also sell a programmer for £50 which works with the Xilinx software. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150811
> Is there an Altera Cyclone Based FPGA Dev Board that allows programming > via USB cable? > Does this exist? Yes. Altera sells the Cyclone III FPGA Starter Kit (DK-START-3C25N). I have one and can confirm it meets your stated requirements. JJSArticle: 150812
Am 14.02.2011 15:28, schrieb jack: > I have a 4 yr old xilinx spartan-3 starter kit which came with a > parallel port JTAG programming cable. My desktop with the parallel > port died recently. As desktops/laptops no longer ship with parallel > port so i am looking for a USB programming cable. However the one > available from Xilinx is for 225$ which is pretty steep for me. > > Any suggestions for alternative cheaper USB JTAG programming cable for > xilinx boards ? You can get low-cost parallel ports for PCI OR PCI-E in your local mall and stay with the cable that works. OK, it consumes a slot in your desktop. regards, GerhardArticle: 150813
On Feb 14, 2:28 pm, jack <postbox4j...@gmail.com> wrote: > Hi, > > I have a 4 yr old xilinx spartan-3 starter kit which came with a > parallel port JTAG programming cable. My desktop with the parallel > port died recently. As desktops/laptops no longer ship with parallel > port so i am looking for a USB programming cable. However the one > available from Xilinx is for 225$ which is pretty steep for me. > > Any suggestions for alternative cheaper USB JTAG programming cable for > xilinx boards ? > > Regards, I use one of these: http://www.absolute-data-services.co.uk/xilinx_platform_usb_cable.htmArticle: 150814
On Feb 9, 8:46=A0am, "mcholbi" <miguel.cholbicollados@n_o_s_p_a_m.aes- aero.com> wrote: > I would like to know your opinion about this. Do you have any experience > with Altium? Would you use a non-vendor tool to design your FPGA? We thin= k > that maybe Altium looks very good (the idea, the results...) but maybe it > isn't reliable enough to handle our big project. Use Altium for schematic capture and PCB layout. That is what the tool is meant to use. Use Libero and Synplify for the FPGA synthesis and implementation. That is what those tools are meant to do. We use Altium Designer for PCB layout and schematics and it's great for that. Its VHDL simulator is crap and chokes on some basic constructs (or at least it did when I tested it last year). Its project management structure gets in the way of proper source-code control for FPGA designs, where one would prefer to keep synthesizable sources separate from test benches, synthesis/fitter project files, etc. We never saw the point of wasting a PCB layout license so we could do FPGA synthesis or simulation. Apparently, we were not alone, because Altium slashed the price of the tool from well over $13K per seat to about $3500 per seat. They kept touting the whole notion of "integrated design environment" which did not reflect the way that real companies work (dedicated layout person who never touches FPGA synthesis/simulation or 8051 firmware) and nobody was buying it. -aArticle: 150815
After some study and a lot of discussions with colleagues and friends I would like to pin down the reasons why I have always believed that a finite state machine (FSM) _is not_ a counter and at the same time try to explain why a counter is a very special FSM (hope the thread will not be too hot!). I will start with my definitions and proceed with conclusions. _Definition_: an FSM is a mathematical abstraction used to describe a particular process or model. It consists of states which carry no information about the history of the process (*1*) and of arcs which define the conditions to move from one state to another one. *note*: every state may have multiple incoming arcs and multiple outgoing arcs. Formally one can say the following: given a set of states S and a set of inputs I, it exists s_next = f(s_curr, i) which belongs to S (where i belongs to I and s_curr belong to S). Iff (not a typo) the function f(s, i) = f(i) for each state s, then our FSM is describing a counter, since there are no multiple outgoing/incoming arcs in any state. Every state is the same and next state is only function of the input (so called "event"). In this case we can not only determine what will be the next state but also the "previous state" (since it will be the nth-1 next state where n is the periodicity of the counter). Usually, together with the description of the states and the arcs, comes a description of the output function, where the outputs may be a function of the inputs and/or the current state (Mealy/Moore). In this case the behavioral model of a process does not need any additional information to be described. _Definition_: a counter is a device which stores the number of times a particular event has occurred since a certain moment in time. Given this definition we cannot define multiple arcs from one state of the counter to the other, since they are all the same. Therefore some additional information (=states) would be needed to define the behavioral model of the process. Strictly speaking I should say that an FSM and a counter are completely different objects, sitting on different levels. An FSM is a "way" to describe a process such that given the state it is possible to predict the next state of the process according to the current inputs. A counter can not model anything, it can simply count the number of events. IMHO whenever there is a need of a sequence of actions (set/reset bits or outputs) that is "fixed", a counter may be handy, even though most of the times the sequence inherit a structure that is best described with an FSM. Any comment is appreciated! Al (*1*) think about the liquid state of a material, like water. Given its state it is not possible to determine whether it came from ice or from gas. Same may happen in a logical device like a flip-flop, it is not possible to know the previous state unless we stored the history of the input, while it is possible to know the next state given the current input. These considerations may be helpful when we are considering phenomena which may upset the state of a register accidentally and putting our system at risk. -- Alessandro Basili CERN, PH/UGC Electronic EngineerArticle: 150816
Alessandro Basili <alessandro.basili@cern.ch> wrote: > After some study and a lot of discussions with colleagues and friends I > would like to pin down the reasons why I have always believed that a > finite state machine (FSM) _is not_ a counter and at the same time try > to explain why a counter is a very special FSM (hope the thread will not > be too hot!). > _Definition_: an FSM is a mathematical abstraction used to describe a > particular process or model. It consists of states which carry no > information about the history of the process (*1*) and of arcs which > define the conditions to move from one state to another one. > *note*: every state may have multiple incoming arcs and multiple > outgoing arcs. With the usual definition, a digital computer is a (very complicated) finite state machine. (snip) > _Definition_: a counter is a device which stores the number of times a > particular event has occurred since a certain moment in time. > Given this definition we cannot define multiple arcs from one state of > the counter to the other, since they are all the same. Therefore some > additional information (=states) would be needed to define the > behavioral model of the process. Okay, but consider even the 7493, pretty early in the TTL line. That is, if I remember right, a loadable synchronous up/down counter. On any clock cycle, you can load a new count, increment, decrement, or keep the count constant. In your arc sense, up, down, and stay the same are three arcs into, and out of, each state. But load allows you to go from any state to any other state! > Strictly speaking I should say that an FSM and a counter are completely > different objects, sitting on different levels. An FSM is a "way" to > describe a process such that given the state it is possible to predict > the next state of the process according to the current inputs. > A counter can not model anything, it can simply count the number of events. It seems to me that counters can be a lot more complex that you indicate. Note that with an up/down counter, you lose history if up/down can change, or if load was active. -- glenArticle: 150817
On Mon, 14 Feb 2011 06:28:45 -0800 (PST), jack <postbox4jack@gmail.com> wrote: >Hi, > >I have a 4 yr old xilinx spartan-3 starter kit which came with a >parallel port JTAG programming cable. My desktop with the parallel >port died recently. As desktops/laptops no longer ship with parallel >port so i am looking for a USB programming cable. However the one >available from Xilinx is for 225$ which is pretty steep for me. > >Any suggestions for alternative cheaper USB JTAG programming cable for >xilinx boards ? > >Regards, I got one of these recently - not used it yet but build quality looks good - possibly not made by Xilinx.... http://cgi.ebay.co.uk/Xilinx-FPGA-CPLD-USB-download-Cable-JTAG-/150560914094?pt=LH_DefaultDomain_0&hash=item230e213aaeArticle: 150818
On 02/14/2011 06:08 PM, Mike Harrison wrote: > On Mon, 14 Feb 2011 06:28:45 -0800 (PST), jack<postbox4jack@gmail.com> wrote: > >> Hi, >> >> I have a 4 yr old xilinx spartan-3 starter kit which came with a >> parallel port JTAG programming cable. My desktop with the parallel >> port died recently. As desktops/laptops no longer ship with parallel >> port so i am looking for a USB programming cable. However the one >> available from Xilinx is for 225$ which is pretty steep for me. >> >> Any suggestions for alternative cheaper USB JTAG programming cable for >> xilinx boards ? >> >> Regards, > > I got one of these recently - not used it yet but build quality looks good - possibly not made by > Xilinx.... > http://cgi.ebay.co.uk/Xilinx-FPGA-CPLD-USB-download-Cable-JTAG-/150560914094?pt=LH_DefaultDomain_0&hash=item230e213aae Heh. That looks like a knock-off. Not sure about other countries, but it's possible one could have Customs issues coming into the US.Article: 150819
On 2/14/2011 8:05 PM, Steven Hirsch wrote: > On 02/14/2011 06:08 PM, Mike Harrison wrote: >> On Mon, 14 Feb 2011 06:28:45 -0800 (PST), jack<postbox4jack@gmail.com> >> wrote: >> >>> Hi, >>> >>> I have a 4 yr old xilinx spartan-3 starter kit which came with a >>> parallel port JTAG programming cable. My desktop with the parallel >>> port died recently. As desktops/laptops no longer ship with parallel >>> port so i am looking for a USB programming cable. However the one >>> available from Xilinx is for 225$ which is pretty steep for me. >>> >>> Any suggestions for alternative cheaper USB JTAG programming cable for >>> xilinx boards ? >>> >>> Regards, >> >> I got one of these recently - not used it yet but build quality looks >> good - possibly not made by >> Xilinx.... >> http://cgi.ebay.co.uk/Xilinx-FPGA-CPLD-USB-download-Cable-JTAG-/150560914094?pt=LH_DefaultDomain_0&hash=item230e213aae >> > > Heh. That looks like a knock-off. Not sure about other countries, but > it's possible one could have Customs issues coming into the US. I got one of those (from the same source) a few months ago. It took longer to get to me than it would from inside the country (I'm in the USA), but there were no customs issues and it has worked fine for me. Impact recognizes it as a standard cable.Article: 150820
On 14 Feb., 23:17, Alessandro Basili <alessandro.bas...@cern.ch> wrote: > After some study and a lot of discussions with colleagues and friends I > would like to pin down the reasons why I have always believed that a > finite state machine (FSM) _is not_ a counter and at the same time try > to explain why a counter is a very special FSM (hope the thread will not > be too hot!). > I will start with my definitions and proceed with conclusions. > > _Definition_: an FSM is a mathematical abstraction used to describe a > particular process or model. It consists of states which carry no > information about the history of the process (*1*) and of arcs which > define the conditions to move from one state to another one. > *note*: every state may have multiple incoming arcs and multiple > outgoing arcs. > > Formally one can say the following: given a set of states S and a set of > inputs I, it exists s_next = f(s_curr, i) which belongs to S (where i > belongs to I and s_curr belong to S). > > Iff (not a typo) the function f(s, i) = f(i) for each state s, then our > FSM is describing a counter, since there are no multiple > outgoing/incoming arcs in any state. Every state is the same and next > state is only function of the input (so called "event"). > In this case we can not only determine what will be the next state but > also the "previous state" (since it will be the nth-1 next state where n > is the periodicity of the counter). > > Usually, together with the description of the states and the arcs, comes > a description of the output function, where the outputs may be a > function of the inputs and/or the current state (Mealy/Moore). In this > case the behavioral model of a process does not need any additional > information to be described. > > _Definition_: a counter is a device which stores the number of times a > particular event has occurred since a certain moment in time. > > Given this definition we cannot define multiple arcs from one state of > the counter to the other, since they are all the same. Therefore some > additional information (=states) would be needed to define the > behavioral model of the process. > > Strictly speaking I should say that an FSM and a counter are completely > different objects, sitting on different levels. An FSM is a "way" to > describe a process such that given the state it is possible to predict > the next state of the process according to the current inputs. > A counter can not model anything, it can simply count the number of events. > > IMHO whenever there is a need of a sequence of actions (set/reset bits > or outputs) that is "fixed", a counter may be handy, even though most of > the times the sequence inherit a structure that is best described with > an FSM. > > Any comment is appreciated! > > Al > > (*1*) think about the liquid state of a material, like water. Given its > state it is not possible to determine whether it came from ice or from > gas. Same may happen in a logical device like a flip-flop, it is not > possible to know the previous state unless we stored the history of the > input, while it is possible to know the next state given the current > input. These considerations may be helpful when we are considering > phenomena which may upset the state of a register accidentally and > putting our system at risk. > > -- > Alessandro Basili > CERN, PH/UGC > Electronic Engineer Hi Allessandro, it's true, that a finite state machine (FSM) _is not, but can be,_ a counter and a counter is a special case of a FSM. That in a simple counter the past and future states can be predicted does not disqualify the counter to be an FSM. We just have the rare situation, that all inputs at all times are known, since there are none. If we had that information for any other FSM, it would be the same situation. The unpredictability and unknown state history of an FSM is just due to the missing knowledge of the input values after reset/pon. It is not required for an FSM to have multiple arcs going from one state to another. Also, it is not required for an FSM to have any output logic at all. This is called a Medvedev state machine. So, the most simple FSM would be a Toggle FF (or 1 bit counter if you like). Once you need more than two states, you have to decide. You can either expand the number of state bits, which leads to the common FSM architectures with a state register and a feedback logic. Or you can connect multiple two-state-FSMs. This is done in FPGAs when you create a One-State-Hot FSM. (You can generate a 1 state hot code with a common FSM-architecture too, but that would enlarge the feedback logic unneccessarily.) Your Definition of a counter is ok, but I can't follow your conclusions. When the counting value has to change due to an event (which is normally the clock) you have to store that value. FSM states can be coded in any fashion, as long as they are well- defined. So there's no need for an extra state beside the counting value. The counting value _is_ the state of that particular FSM. (reminder: Medvedev FSM) That a counter can not model anything also is a claim that's worth discussion. What do you mean by "model sth."? A counter is a model in itself, since it is limited (Finite). The number of events is not finite (theoretically). Of course a simple counter for itself has no big practical use, but that holds for most FSMs. Even a CPU (which, as Glen states too, can be seen as a big FSM or a bunch of FSMs) is absolutely useless for itself. It just becomes a sense with attached Interfaces, memory and a programm. And as part of a CPU we also find at least one counter, the Programm Counter, which serves to address the programm memory. Many things that need to act repetitively in a sequential order can be controlled by a counter. Provided that counting can be done in any binary coding scheme. We as humans are reluctant to accept these codes as "counting" in the common sense, so we already accept these machines as FSMs. (And Mr. Medvedev put his name on them. :-) ) One more thing about the predictability of a counter. Due to it's limitation, you can only trace back it's history up to a certain point. It's initial value. Before that, you cant tell if it has already counted a number of cycles, or if it had started at just that time. And even if it had counted some full cycles before, you can't tell how many. That information is lost in time. So there are many arguments (practical and theoretical) that validate a counter as a (special form of) FSM. Have a nice synthesis EilertArticle: 150821
In article <8rridqF3ndU1@mid.individual.net>, Alessandro Basili <alessandro.basili@cern.ch> writes: >On 2/11/2011 8:38 PM, Hal Murray wrote: >> In article<3292f4d0-26e9-44fe-9b09-2904190036e0@w36g2000vbi.googlegroups.com>, >> The key idea is that full and empty aren't really synchronous >> with either read or write clock so you can't just feed them >> into a FSM and expect things to work if the tools don't complain. >I am sorry but I don't understand why not. An FSM can always poll for >the status bit, fifo-full on the write side and fifo-empty on the read >side, and go at full speed until the bit is set. This will require a >poll at each write/read operation. Am I missing something? Assume you have a FSM running on the write clock. It looks at the full flag. The not-full to full transition is synchronous. The full to not-full is not synchronous so your FSM may get in trouble. >> If you are smart enough, you can think about the issue and use >> the going-full path without the delay of a synchronizer as long as >> you are careful about the un-full path. >Which delay of a synchronizer? As far as I understood there's crossing >over the two clock domains, data are moved in a memory with one clock >and retrieved with another one. The classic synchronizer is 2 FFs and thus 2 cycles of delay. Thus if it goes full, your FSM won't see that for 2 more cycles. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 150822
>After some study and a lot of discussions with colleagues and friends I >would like to pin down the reasons why I have always believed that a >finite state machine (FSM) _is not_ a counter and at the same time try >to explain why a counter is a very special FSM (hope the thread will not >be too hot!). <snip> Why has it taken you so long to work this out? --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150823
On Feb 15, 2:05=A0am, Chris Abele <ccab...@yahoo.com> wrote: > On 2/14/2011 8:05 PM, Steven Hirsch wrote: > > > > > On 02/14/2011 06:08 PM, Mike Harrison wrote: > >> On Mon, 14 Feb 2011 06:28:45 -0800 (PST), jack<postbox4j...@gmail.com> > >> wrote: > > >>> Hi, > > >>> I have a 4 yr old xilinx spartan-3 starter kit which came with a > >>> parallel port JTAG programming cable. My desktop with the parallel > >>> port died recently. As desktops/laptops no longer ship with parallel > >>> port so i am looking for a USB programming cable. However the one > >>> available from Xilinx is for 225$ which is pretty steep for me. > > >>> Any suggestions for alternative cheaper USB JTAG programming cable fo= r > >>> xilinx boards ? > > >>> Regards, > > >> I got one of these recently - not used it yet but build quality looks > >> good - possibly not made by > >> Xilinx.... > >>http://cgi.ebay.co.uk/Xilinx-FPGA-CPLD-USB-download-Cable-JTAG-/15056..= . > > > Heh. That looks like a knock-off. Not sure about other countries, but > > it's possible one could have Customs issues coming into the US. > > I got one of those (from the same source) a few months ago. =A0It took > longer to get to me than it would from inside the country (I'm in the > USA), but there were no customs issues and it has worked fine for me. > Impact recognizes it as a standard cable. I just ordered one, instead of the Digilent unit I mentioned. It's obviously a clone of the Xilinx unit. I paid extra for express delivery so I should have it in a few days, I'll report back on how it works.Article: 150824
I just checked on Ebay for other suppliers of those Chinese-made units, there are several of them: http://shop.ebay.co.uk/?_from=R40&_trksid=p5197.m570.l1313&_nkw=xilinx+platform+cable&_sacat=See-All-Categories There is probably one company making them all.
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