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
Andrew Barnish <barnish@hotmail.com> wrote in message news:c92b233a.0110061528.3007dd89@posting.google.com... > "Sergio Masci" <sergio@NO.SPAM.xcprod.com> wrote in message news:<ULmv7.11508$GT3.1674495@news2-win.server.ntlworld.com>... > > If I read this right, you would have a maximum of 256 states and 4 events. > > Presumably you could half the number of states and double the number > > of events? > > > > Yes, there are different possibilities depending on the > size/configuration of the ROM. I think that for very large state > machines this will perform better than the LUT equivalent, although I > haven't done too many experiments. > The other advantage is that you can make use of blockram that might be > totally unused in the design, saving a fair amount of logic cells. > > > I might be able to get ZMech to do this for you with a few tweaks.What > > would the tables you require (raw hex) look like. > > > > maybe something like > > <input state>, <event>, <output state> > > <input state>, <event>, <output state> > > <input state>, <event>, <output state> > > > > How would the binary be packed? > > > > > Yes this is the kind of description that I would like automatically > converted into the ROM hex. Describing the connections of the block > ram is no problem. Deriving the contents of the ROM is the > brain-hurting part. Ideally, I would like to infer the blockram > implementation from a traditional FSM description as registers and a > large case statement described in VHDL. Maybe, FPGA Synthesis tools > will do this one day..... > > I believe FSMs implemented in PROMs were common in the past - what > tools did people use back then in order to derive the PROM contents? > > What is this ZMech you mention? > > Cheers, > > Andy ZMech is a state machine development tool. It allows you to design complex state machines useing state diagrams. It has a built in diagram editor and is capable of interactively debugging state machines directly on the diagram. One version generates binary executable code targetted at the PIC 16 series and comes with a built in simulator for debugging multi MCU designs (again on the original diagram). ZMech is built using a meta-CASE tool and it would be a simple mater to change the code generator (actually short circuit most of it) to generate some hex tables from the state diagrams. You would need to specify what YOU want the tables to look like. Currently state transitions require a nominated function, this would probably need to be changed to an output value. ZMech and docs can be found at http://www.xcprod.com/titan Regards Sergio MasciArticle: 35476
I worked with several of these in the early 80's. No special tools are needed, The outputs consist partly of the next state
vector. The input selects two or more addresses. It is pretty straight forward. The only time it gets tricky is if you start
being creative with the state assignments so that next state bits double as outputs and arranging the states so as to minimize
the input mux if needed.
Peter brought up a good point regarding the speed. The slow speed of the block RAMs is due mostly to the long delay for the
enable, and due to routing to get signals to/from the block RAM. In the case of a state machine, many of your outputs are
wrapped back around to the input, so you avoid some of the penalty usually associated with the block RAMs. You are also not
using the write enable, and you can get away with not using enables on reads (tying it high), so you can eliminate the worst
paths.
Andrew Barnish wrote:
> "Sergio Masci" <sergio@NO.SPAM.xcprod.com> wrote in message news:<ULmv7.11508$GT3.1674495@news2-win.server.ntlworld.com>...
> > If I read this right, you would have a maximum of 256 states and 4 events.
> > Presumably you could half the number of states and double the number
> > of events?
> >
>
> Yes, there are different possibilities depending on the
> size/configuration of the ROM. I think that for very large state
> machines this will perform better than the LUT equivalent, although I
> haven't done too many experiments.
> The other advantage is that you can make use of blockram that might be
> totally unused in the design, saving a fair amount of logic cells.
>
> > I might be able to get ZMech to do this for you with a few tweaks.What
> > would the tables you require (raw hex) look like.
> >
> > maybe something like
> > <input state>, <event>, <output state>
> > <input state>, <event>, <output state>
> > <input state>, <event>, <output state>
> >
> > How would the binary be packed?
> >
>
> Yes this is the kind of description that I would like automatically
> converted into the ROM hex. Describing the connections of the block
> ram is no problem. Deriving the contents of the ROM is the
> brain-hurting part. Ideally, I would like to infer the blockram
> implementation from a traditional FSM description as registers and a
> large case statement described in VHDL. Maybe, FPGA Synthesis tools
> will do this one day.....
>
> I believe FSMs implemented in PROMs were common in the past - what
> tools did people use back then in order to derive the PROM contents?
>
> What is this ZMech you mention?
>
> Cheers,
>
> Andy
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35477Ray Andraka schrieb: > > Peter brought up a good point regarding the speed. The slow speed of the block RAMs is due mostly to the long delay for the > enable, and due to routing to get signals to/from the block RAM. In the case of a state machine, many of your outputs are > wrapped back around to the input, so you avoid some of the penalty usually associated with the block RAMs. You are also not > using the write enable, and you can get away with not using enables on reads (tying it high), so you can eliminate the worst > paths. First question. Why are the enable signals so slow? Second question. Does the static timing analyzer recognize that the enables are not used (tied to a constant) and then ignore these timing parameters? -- MFG FalkArticle: 35478
Peter Alfke wrote: > Since I indirectly started this thread ( it started with quoting my article in > TechXclusives ) let me give my $ 0.02 worth: > > Tools: > There is no software tool, but is it really needed? > You have to decide anyhow exactly what to do in each state, where to branches and what > outputs to activate. And that is really the only information you have to throw into the > ROM. So, what would the software do for you? > IMO if such a thing is going to be useful it needs to be integrated in some way into an HDL design flow. In particular the state transition description needs to ``compile'' down to a bunch of BlockRAM INIT parameters that can be merged into the UCF/PCF - this could be a simple Perl script or something more sophisticated built from yacc/lex.. Interestingly Synplify can already o Infer simple LUT based ROMs from ``case'' statements. o In some limited circumstances it can infer BlockRAMs from HDL code. Putting these 2 together gives the nice possibility of inferring a BlockRAM based FSM from HDL code. Condition inputs: > The basic design has a limited number of encoded branch control inputs. It may be > necessary to expand this with an extra multiplexer. > > Just to explain the beauty of the concept: > In one Virtex-II BlockRAM you can implement a 128-state FSM with 4-way branch and 29 > outputs. What about us poor b*****s who are stuck with antedeluvian Virtex-Es ? Reading this NG its getting to the point where I'm thinking of putting a sticky label over the FPGA to reduce embarrassment. It will read ``When I grow up I want to be a Virtex-II''. :o). More seriously using 2 512x8 BRAMs (or both parts of a single one ?) in parallel gets me 32-state, 4-way branch, 11 outputs.Article: 35479
I have a problem with Altera software.
I'm non able to drive two pins with the *same*
LCELL.
This code shows the core of the problem:
LIBRARY ieee;
USE ieee.std_logic_1164.all;
ENTITY dout IS
PORT
(
a, b, c1, c2 : IN STD_LOGIC;
o1, o2 : OUT STD_LOGIC
);
END dout;
ARCHITECTURE behav OF dout IS
SIGNAL n : STD_LOGIC;
BEGIN
n <= a AND b;
o1 <= n WHEN c1='1' ELSE 'Z';
o2 <= n WHEN c2='1' ELSE 'Z';
END behav;
I'm shure it could be done with a single LCELL,
but MAX+plus II (vers. 10.0) generates two.
Any advice to avoid this waste?
Luigi
Article: 35480
I wouldn't call those 'stuck' with the Virtex-E unfortunate. I've found that a virtexE of a
given gate density is actually more capable for DSP processing than a VirtexII of the same
density. Consider that an XC2V1000 has a mere 5120 slices compared with 12288 in the
XCV1000e. The gate count in the V-2s is eaten up in memory and multipliers, and the
multipliers are quite a bit slower than what you can do in the fabric. The net result is I can
usually pack more processing power into an equivalent E part.
Balancing out the more constrained resources however, there is the ease of use. With the
VirtexII, one needn't be as well versed in computing hardware to get something that works.
This makes FPGA DSP more available to the average designer.
Rick Filipkiewicz wrote:
> Peter Alfke wrote:
>
> > Since I indirectly started this thread ( it started with quoting my article in
> > TechXclusives ) let me give my $ 0.02 worth:
> >
> > Tools:
> > There is no software tool, but is it really needed?
> > You have to decide anyhow exactly what to do in each state, where to branches and what
> > outputs to activate. And that is really the only information you have to throw into the
> > ROM. So, what would the software do for you?
> >
>
> IMO if such a thing is going to be useful it needs to be integrated in some way into an HDL
> design flow. In particular the state transition description needs to ``compile'' down to a
> bunch of BlockRAM INIT parameters that can be merged into the UCF/PCF - this could be a
> simple Perl script or something more sophisticated built from yacc/lex.. Interestingly
> Synplify can already
>
> o Infer simple LUT based ROMs from ``case'' statements.
>
> o In some limited circumstances it can infer BlockRAMs from HDL code.
>
> Putting these 2 together gives the nice possibility of inferring a BlockRAM based FSM from
> HDL
> code.
>
> Condition inputs:
>
> > The basic design has a limited number of encoded branch control inputs. It may be
> > necessary to expand this with an extra multiplexer.
> >
> > Just to explain the beauty of the concept:
> > In one Virtex-II BlockRAM you can implement a 128-state FSM with 4-way branch and 29
> > outputs.
>
> What about us poor b*****s who are stuck with antedeluvian Virtex-Es ? Reading this NG its
> getting to the point where I'm thinking of putting a sticky label over the FPGA to reduce
> embarrassment. It will read ``When I grow up I want to be a Virtex-II''. :o).
>
> More seriously using 2 512x8 BRAMs (or both parts of a single one ?) in parallel gets me
> 32-state, 4-way branch, 11 outputs.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35481
You'll have to ask the folks at Xilinx why. If you look at the timing for them, you'll see that the setup and hold times for the
enable, write enable and reset are more than twice the delays for the address and data inputs. Yes, the static timing analyzer
will ignore those inputs if they are just tied high. If they come from logic, however, they do not get ignored. Unfortunately,
in most cases you use the BRAMs as RAM, which often means that the write enable has to be used. There is room to be creative in
the design so that the enables don't get used.
Falk Brunner wrote:
> Ray Andraka schrieb:
> >
>
> > Peter brought up a good point regarding the speed. The slow speed of the block RAMs is due mostly to the long delay for the
> > enable, and due to routing to get signals to/from the block RAM. In the case of a state machine, many of your outputs are
> > wrapped back around to the input, so you avoid some of the penalty usually associated with the block RAMs. You are also not
> > using the write enable, and you can get away with not using enables on reads (tying it high), so you can eliminate the worst
> > paths.
>
> First question. Why are the enable signals so slow?
>
> Second question. Does the static timing analyzer recognize that the
> enables are not used (tied to a constant) and then ignore these timing
> parameters?
>
> --
> MFG
> Falk
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35482Ray Andraka wrote: > I wouldn't call those 'stuck' with the Virtex-E unfortunate. I've found that a virtexE of a > given gate density is actually more capable for DSP processing than a VirtexII of the same > density. Consider that an XC2V1000 has a mere 5120 slices compared with 12288 in the > XCV1000e. The gate count in the V-2s is eaten up in memory and multipliers, and the > multipliers are quite a bit slower than what you can do in the fabric. The net result is I can > usually pack more processing power into an equivalent E part. > > Balancing out the more constrained resources however, there is the ease of use. With the > VirtexII, one needn't be as well versed in computing hardware to get something that works. > This makes FPGA DSP more available to the average designer. > > Rick Filipkiewicz wrote: Yeah. I was only partly joking. In slice count & number of BRAMs (o.k. they are bigger) the XC2V1000 is ~equivalent to the XCV400E. I expect Xilinx might claim that improved interconnect will allow higher density designs to maintain timing more easily and/or move the point where serious floorplanning is needed to get increased speed - ease of use again. I'm only considering the V-2s in order to get DDR DRAM going with a 125MHz target speed for the system clock although it does turn out that the, as yet unreleased, XC2V1500 (~XCV600E) is a very good way of meeting some high pincount requirements without paying through the nose for logic I don't need. Also I seem to remember some claim that in speed terms the -5 V-2 is ~= the -8 V-E. This discussion has decided me to at least try the BRAM FSM thing, I've got 22 of them hanging around not earning their keep.Article: 35483
Yeah, in the V2, I think we'll be forced to look for ways to use the multipliers and BRAMs in ways they
were not intended in order to fully ustilize the device. DDR pins is a win for V2. DDR is a royal
pain in the patoot to pull off in the virtexE. 125 mHz internal clock isn't too bad, although you'll
have to either be really careful in your rtl or do a bit of floorplanning to make it happen in a -6.
It is certainly not an unreachable target though.
Rick Filipkiewicz wrote:
> Ray Andraka wrote:
>
> > I wouldn't call those 'stuck' with the Virtex-E unfortunate. I've found that a virtexE of a
> > given gate density is actually more capable for DSP processing than a VirtexII of the same
> > density. Consider that an XC2V1000 has a mere 5120 slices compared with 12288 in the
> > XCV1000e. The gate count in the V-2s is eaten up in memory and multipliers, and the
> > multipliers are quite a bit slower than what you can do in the fabric. The net result is I can
> > usually pack more processing power into an equivalent E part.
> >
> > Balancing out the more constrained resources however, there is the ease of use. With the
> > VirtexII, one needn't be as well versed in computing hardware to get something that works.
> > This makes FPGA DSP more available to the average designer.
> >
> > Rick Filipkiewicz wrote:
>
> Yeah. I was only partly joking. In slice count & number of BRAMs (o.k. they are bigger) the
> XC2V1000 is ~equivalent to the XCV400E. I expect Xilinx might claim that improved interconnect will
> allow higher density designs to maintain timing more easily and/or move the point where serious
> floorplanning is needed to get increased speed - ease of use again.
>
> I'm only considering the V-2s in order to get DDR DRAM going with a 125MHz target speed for the
> system clock although it does turn out that the, as yet unreleased, XC2V1500 (~XCV600E) is a very
> good way of meeting some high pincount requirements without paying through the nose for logic I
> don't need.
>
> Also I seem to remember some claim that in speed terms the -5 V-2 is ~= the -8 V-E.
>
> This discussion has decided me to at least try the BRAM FSM thing, I've got 22 of them hanging
> around not earning their keep.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 35485Ben <seabybs@hotmail.com> wrote in message news:TFpv7.13032$GT3.1857396@news2-win.server.ntlworld.com... > Hi, Hi, > I'm doing a literature search for my university project. This is based on > real-time digital video processing using FPGA technology. > > Does anyone out there have any recommendations for book, papers, websites or > magazine articles worth reading, or people worth speaking to on the subject? Look at the website of Celoxica (www.celoxica.com) in the Case study pages. They have several impressive demos that show this (e.g. on their RC-100 eval board). > I've been to Xilix, Altera etc, but want to get as much information as > possible. > > Any information greatly appreciated, > Ben. HermanArticle: 35486
I agree with the original poster's comments. Also, it would be nice if the 'done' signal were available to a user programmable pin in addition to it's regular pin. (Perhaps it could be tri-state isolated from the user pin after configuration). That way, it could be used in address decoding for an eprom shared between configuration bits and microprocessor code. Might save some external gates. Rob http://www.birdcomputer.ca/Article: 35488
Why don't you use "any" pin, rely on the fact that it is 3-stated with weak pull-up during configuration, and make it active Low after configuration. Maybe add a 1 kilohm pull-up... Or am I missing something ? Peter Alfke Rob Finch wrote: > I agree with the original poster's comments. > > Also, it would be nice if the 'done' signal were available to a user > programmable pin in addition to it's regular pin. (Perhaps it could be > tri-state isolated from the user pin after configuration). That way, it > could be used in address decoding for an eprom shared between configuration > bits and microprocessor code. Might save some external gates. > > Rob > http://www.birdcomputer.ca/Article: 35489
Hello VLSI Gurus,
One of my friends is trying to convince me that he with a
team of 3 (inclduing himself) can design a IEEE 802.11 (WAN) compliant
IP (atleast the softcore, i.e. RTL, plus synthesis, Verification etc.)
starting from IEEE Specs within 12 weeks.
The average team expereince is 4 years (or 5 maximum) with hardly
any expereince on Ethernet etc. The team's Verilog strength is also
"moderate" - meaning not so great.
My question to you all experts is: "Is this a realistic schedule"? I
thought a minimum of 6 months is needed.
Thanks a lot for any suggestions (this information will be useful for
my another friend who is willing to join this group).
Sorry for off-topic, off-techincal post.
Kind Regards,
VLSI Engr.
Article: 35490Hi, The Virtex-II (FF1152 Package) PCIX soft core uses Banks 2 and 3. Hence these banks are locked to IOSTANDARD PCIX. But surprisingly since there is no GCLK pin in these two banks, it is using Bank 1 GCLK pin, but the problem is that i require the bank 1 to operate in LVCMOS and hence the PCIX clock pin will have to be in LVCMOS. I just want to get a help in this regard whether the PCIX clock can be driven to a GCLK pin which is configured as a LVCMOS SelectIO. Please help... Warm regards ramaArticle: 35491
Hi, can any body tell me what is the maximum clock speed at which xilinx virtex-2 fpga can work?? It has got 8 DLLs..what is the maximum clock rate they can provide. do i have to divide that frequency for clock stability? Thanks in advance HimanshuArticle: 35492
Rick Filipkiewicz <rick@algor.co.uk> wrote: > Synplify can already > o Infer simple LUT based ROMs from ``case'' statements. > o In some limited circumstances it can infer BlockRAMs from HDL code. > Putting these 2 together gives the nice possibility of inferring a BlockRAM based FSM from HDL code. Also, the ISE 4.1 mapper has a command line switch for mapping logic functions into block RAMs. I haven't tried it, but it sounds kind of neat if you have spare block RAMs. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 35496
In article <3BBF4514.411C73A8@algor.co.uk>, Rick Filipkiewicz
<rick@algor.co.uk> writes
>IIRC there were even some CPUs with ``writeable'' control store that allowed the
>instruction sets to be tailored to some degree [Fairchild Clipper ?].
Nope, the Clipper never had a user-accessible WCS as far as I am aware.
Certainly not in any of the data or appnotes I ever saw as an FAE (for
Intergraph, after they bought the Clipper product from Fairchild).
Several other machines did, though. ISTR some of the CDC and
Burroughs machines had them. And I am aware of at least one British
early-80s design that did (High Level Hardware's Orion - based on
AMD 2910 etc etc. In the instruction decoder there was a pointer
into the writeable microcode; this pointer was visible as a CPU
register; so you could change instruction set on the fly. Scary.)
Anyone for reconfigurable computing? :-)
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 35497
In article <c92b233a.0110061528.3007dd89@posting.google.com>, Andrew
Barnish <barnish@hotmail.com> writes
>I believe FSMs implemented in PROMs were common in the past - what
>tools did people use back then in order to derive the PROM contents?
Pencil and paper, according to my increasingly jaundiced recollections.
Not entirely unreasonable with 256x8 PROMs, but still a b****y pain.
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan.bromley@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 35498
In the VHDL below, I intend to synthesize two FFs: one for the output data
and one for the output tristate. Synthesizing with Synplify for an XC2V40,
I get 3 FFs and my tristate control for the output "SelectedData" is not a
register output.
Synplify notices that my internal tristate bus is not always enabled and
propagates the undriven states through the output data FF.
Do most people expect this behavior? Does 1076.6 address this issue?
Thanks,
Paul Butler
----------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity tristate is
port(
Clk : in std_logic;
EnableOutput : in boolean;
address : in unsigned(3 downto 0);
Data : in std_logic_vector(5 downto 0);
SelectedData : out std_logic
);
end tristate;
architecture rtl of tristate is
signal EnableOutputQ : boolean;
signal iSelectedData : std_logic;
signal SelectedDataQ : std_logic;
begin
TristateMUX:
for i in Data'range generate
iSelectedData <= Data(i) when i=address else 'Z';
end generate TristateMUX;
OutputFFs:
Process(clk)
begin
if rising_edge(clk) then
SelectedDataQ <= iSelectedData;
EnableOutputQ <= EnableOutput;
end if;
end process;
OutputTristate:
SelectedData <= SelectedDataQ when EnableOutputQ else 'Z';
end rtl;
Article: 35499Hi, Talking about pins that could be used for user IO after configuration, there is : - M0 M1 M2 : According to the data sheet (Spartan II, page 13), the state of these pins is only required to be valid on the Low to High transition of INIT (not very clear, would seem more logical if they had a setup time). No matter the exact timing, they obviously are only required at a precise point during configuration and are useless except at that time. After configuration, I see no reason why they could not be used as IO. - HSWAP_EN (Virtex II) Same as M0 .. M2 - CCLK : Obviously, it have no function after configuration is complete, and in most apps, I end up connecting it to another IO pin (when configuration is bit banged by a processor, CCLK is usually connected to some kind of address decoding, and it is used after configuration as a "Chip Select" input). Here too, I can't see any reason for not using it as an IO - TDI TDO TMS TCK In previous series (at least Spartan), these could be used as IO if the boundary scan function was not required. I miss these 4 pins (even if I screwed up once with them and could not properly configure the chip because of random data being fed to them). With proper care, they are great as IO too. - DONE. Here too, as Rob Finch said, I can't see why it's not a user IO after configuration. - PROGRAM. Obviously, this pin can't be used as an input, but it could be used as an Open drain output. Hiz : Well, does nothing ... Low : If properly latched / delayed /cleared, can be used to trigger self reconfiguration. This self reset can be used to restart without using external logic when a faulty condition is detected (or whenever the designer want to reboot the device). ------ Also, as Geoffrey G. Rochat stated, I miss both HDC and LDC pins too. Another pin that might be very useful (if Master Parallel mode goes back) would be a "TDC" pin that would toggle during configuration. Here's how it would work : Initially, it would be a high impedance (or high level) pin, but if the configuration fail, it would go to "0" and start toggling each time the configuration fails. The use would be to connect it to an address pin of the configuration ROM in systems that require the FPGA to start even in case of a failed configuration download. That way, the FPGA would attempt to start from the potentially corrupted configuration data, detect the bad CRC and restart from the original "fail-safe" configuration. This fail-safe mode is needed as soon as a potentially unreliable update must be made (such as remote/modem update), at the expense of a doubled configuration rom size. In applications that don't need the functions, it's very rare not to be able to find any pin in the design that can be either pulled high, or low, or toggled during configuration with no adverse effect. ------ These changes would help mostly with low pin count packages where these ten user IO pins could certainly be put to good use, and since this is all programmable, it would all be backward compatible (except HDC / LDC) for users who don't need them. Also, not loosing pins used for configuration would allow for even more configuration options without loosing more user pins (and/or increasing the number of Power/GND pairs without decreasing the useable pin count). Éric. --------------------------------- Rob Finch wrote: > I agree with the original poster's comments. > > Also, it would be nice if the 'done' signal were available to a user > programmable pin in addition to it's regular pin. (Perhaps it could be > tri-state isolated from the user pin after configuration). That way, it > could be used in address decoding for an eprom shared between configuration > bits and microprocessor code. Might save some external gates. > > Rob > http://www.birdcomputer.ca/
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