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
Has anyone else come across this experience? Run a design (Virtex/Virtex-E, xcv600E in my case) thru Alliance (or Foundation, presumably same P&R engine) version 3.1i, then after upgrading to version 4.1i, the design's timing gets significantly worse even though it's operating on the same EDIF netlist & same UCF file & same "effort" level (max) set in the Design Manager's " Design --> Options... " menu. Is there some trick or switch to make 4.1i get at least as good, preferably better, timing than 3.1i? -- ============================== William Lenihan lenihan3we@earthlink.net ==============================Article: 45601
Gudday All, Has anyone had an attempt at interfacing a WishBone IP core to a CoreConnect bus. My target platform is a VirtexII-Pro. Has anyone developed some sort of bridge code, or if not, have any suggestion of which direction may provide fruitful results. FYI this work is part of a final year project - any help is greatly appreciated, and will be attributed in my final report. Cheers, Mitchell. __________________________________________________________________Article: 45602
I am building a VHDL design, using Xilinx ISE 4.1i
The design uses alternative architectures for some entities, with a
top-level configuration file to bind everything.
The project compiles & simulates with ModelSim, however ISE doesn't
want to handle the configuration. Having successfully compiled all the
lower units, it then reports:
Compiling vhdl file top_cfg.vhd in Library work.
ERROR:HDLParsers:340 - top_cfg.vhd Entity <top_config> does not
exist in library <work>.
Naturally, top_config doesn't exist: it is what I am compiling!!
Here's the first few lines of the config. file:
library work;
configuration top_config of top is
for struct
for all : rstgenr
use entity work.rstgenr(rtl);
end for;
...
Can anyone say how one should compile configurations in ISE?
TIA
Article: 45603On Mon, 29 Jul 2002 08:46:25 GMT, William Lenihan <lenihan3we@earthlink.net> wrote: > >Has anyone else come across this experience? > >Run a design (Virtex/Virtex-E, xcv600E in my case) thru Alliance (or >Foundation, presumably same P&R engine) version 3.1i, then after >upgrading to version 4.1i, the design's timing gets significantly worse >even though it's operating on the same EDIF netlist & same UCF file & >same "effort" level (max) set in the Design Manager's " Design --> >Options... " menu. > >Is there some trick or switch to make 4.1i get at least as good, >preferably better, timing than 3.1i? Yes, upgrade to 4.2i. Regards, Allan.Article: 45604
There is many method to program FLASH. A universal programer always can do it. For debug, you can download via serial port of computer. Best Regards, Cao QingHua PhotonicBridges Inc. "ndesi" <ndesi@talk21.com> wrote in message news:cf531019.0207271342.22447b3f@posting.google.com... > Hello :) > > I want to configure my Virtex II parts with FLASH (Atmel or Intel). > I found app note how to do that > But question is How to Programm FLASH?? > > I am thinking of using CPLD and CPLD Logic convert "Xilinx Parallel > cable III" output to program FLASH > > Is it possible?? > Any other Idea?? > > I want to use Xilinx software and their cable but i can add only CPLD > to my board. > > Thanks In AdvanceArticle: 45605
Actel's antifuse FPGAArticle: 45606
Hi everyone, Although this is not strictly an FPGA question, I thought that someone here should be able to answer it quite easily. Does anyone know of any references on the use of complex FIR low pass filters. It doesn't have to be very informative, as I have already designed some, however I would like to see what other people do. Thanks AdrianArticle: 45607
There is a description of a DA archtecture I've used for complex FIR filters
(complex data, complex coefficient) in my paper "FPGA makes radar on a chip a
reality", which is available at no charge from my website.
Noddy wrote:
> Hi everyone,
>
> Although this is not strictly an FPGA question, I thought that someone here
> should be able to answer it quite easily. Does anyone know of any references
> on the use of complex FIR low pass filters. It doesn't have to be very
> informative, as I have already designed some, however I would like to see
> what other people do.
>
> Thanks
>
> Adrian
--
--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: 45608
You are only partially correct. The input words need to be sign extended
rather than zero extended unless the input data is unsinged data (usually
not the case except in video). The wordlength only has to be extended if
the architecture of your fiter requires it. Scaling accumulator
multipliers, for example have a serial input and a parallel output, so the
serial input does not have to be extended at all. A serial distributed
arithmetic filter uses scaling accumulators to do the multiply, so you avoid
the need for input extension because the partial sums are accumulated as
parallel arithmetic. Only the partial sums are computed serially. See the
distributed arithmetic and multiplier pages on my website for a more
complete explanation.
hristo wrote:
> hello,
> may be basic question
> if someone has to implement an FIR using bit serial, he has to see the
> output wordlength, thus the FIR bit growth. Then, he needs to expand the
> input data with zero to have regular wordlength through the structure
>
> in parrallel we have not to do that
>
> what about digit serial, should we still need to expand the input data
> with zero digits
>
> Many thanks
--
--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: 45609
It may very well be tapping it. The virtex architecture supports tapping the carry chain
and sending it out the XB and YB outputs of the slice. I have had trouble in the past
getting the software to use that tap when the carry out to the next slice is also used,
although I don't recall if it was a xilinx problem or a synplify problem. If you are
using 4.x there is a good possibility that it is properly tapping the carry chain. If you
are using the paid version of the Xilinx software, you can open the FPGA editor and
examine the results directly. If not, you can tell from the timing report if you have it
show all timing and then you find the carry chain in question.
Dmitri Katchalov wrote:
> Thanks again everyone.
>
> Using your suggestions I've managed to implement PIC-style
> ADD/SUB/INC/DEC with carry and half-carry out in just 4 slices, see code below.
> I'm not sure about the polarity of the borrow bit though.
>
> Synthesis infers 2 5-bit adders, later optimised into 4-bit
> adders with carry in/out. P&R places them in one column one immediately
> on top of another (in otherwise empty FPGA). I don't have suffucient
> knowledge to tell from all those the reports whether the carry chain
> is broken or continues over. It does seem to continue over.
>
> Here is the code, comments appreciated.
>
> Regards,
> Dmitri
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.NUMERIC_STD.ALL;
>
> entity alu_adder is
> Port ( A,B: in std_logic_vector(7 downto 0);
> op: in std_logic_vector(1 downto 0);
> Y: out std_logic_vector(7 downto 0);
> carry_out: out std_logic;
> dc_out: out std_logic );
> constant ADD : std_logic_vector(1 downto 0) := "00";
> constant SUB : std_logic_vector(1 downto 0) := "01";
> constant DEC : std_logic_vector(1 downto 0) := "10";
> constant INC : std_logic_vector(1 downto 0) := "11";
> end entity alu_adder;
>
> architecture Behavioral of alu_adder is
> begin
> process( A, B, op )
> variable tmp: std_logic_vector(7 downto 0);
> variable lo_nibble, hi_nibble: unsigned(5 downto 0);
> variable cin: std_logic;
> begin
> case op is
> when INC => tmp := (others => '0'); cin := '1';
> when DEC => tmp := (others => '1'); cin := '0';
> when SUB => tmp := not B; cin := '1';
> when ADD => tmp := B; cin := '0';
> when others => tmp := (others => '-'); cin := '-';
> end case;
>
> lo_nibble := unsigned('0' & A(3 downto 0) & cin ) +
> unsigned('0' & tmp(3 downto 0) & cin );
>
> hi_nibble := unsigned('0' & A(7 downto 4) & lo_nibble(5) ) +
> unsigned('0' & tmp(7 downto 4) & lo_nibble(5) );
>
> Y <= std_logic_vector( hi_nibble(4 downto 1) & lo_nibble(4 downto 1));
> dc_out <= lo_nibble(5);
> carry_out <= hi_nibble(5);
> end process;
> end architecture Behavioral;
>
> Ray Andraka <ray@andraka.com> wrote in message news:<3D43FE74.BC6780AD@andraka.com>...
> > In order to tap the carry chain you need to add an extra bit in the carry
> > chain. The synthesis tools won't do that for you, and in fact will not
> > infer a caryy chain for less than about 7 bits. Using 2 four bit counters
> > you incur the delay to get off and then onto the second chain, where with a
> > single chain you only incur ~100ps. With 2 4 bit counts, it is likely not
> > your worst case path anyway, so for the sake of simplicity, readability and
> > maintainability of the code, it is probably better to just infer them as
> > separate counters. My point was that what you asked about could be done,
> > but it is not done automatically by the tools and it takes a bit of
> > finabling to make it work.
> >
> > Eric Smith wrote:
> >
> > > > * How do I get the half-carry bit out of the 8bit adder? I guess I can
> > > > instantiate/infer two separate 4bit adders. Is there a better way?
> > >
> > > Ray Andraka <ray@andraka.com> writes:
> > > > It can be done, but it takes a little mind-bending. Basically, you
> > > > need to turn your 8 bit adder into a 9 bit one with bit 4 being a
> > > > dummy so that you can pull out the carry out through the bit. It
> > > > takes a bit of caressing the tools to make them infer it.
> > >
> > > Is there any advantage to doing that rather than two four-bit adders?
> > > For instance, with two four-bit adders, does the synthesizer not
> > > recognize that it can continue the carry chain between them? Or
> > > does the FPGA not allow you to tap the carry from intermediate stages
> > > of the chain?
--
--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: 45610"Thomas Wollinger" <wollinger@crypto.ruhr-uni-bochum.de> wrote in message news:ai2om4$10v3kt$1@ID-137468.news.dfncis.de... > Hi everybody, > > I am looking for a FPGA that I have to use in a secure manner. I have to do > a project in which the FPGA is use in a 'military' like environment. > > Can somebody tell me which vendors and FPGA families are out there with > 'special' security features? and which security features that are and what > are they good for? > > The FPGA can use any technology (SRAM, antifues, flash ...), but it has to > be secure against as much attacks as possible. > > Thanks everybody for your time. > > I really appreciate your help > > Thomas How about putting an SRAM based FPGA on a special battery circuit such that it stays configured when power is off. That way when someone tries to break into it, it loses configuration and all info is gone. You can make it such that when the product cover is removed, power is removed from the FPGA. Any SRAM FPGA will suffice, but Xilinx comes to mind! Simon Ramirez, Consultant Synchronous Design, Inc. Oviedo, FL USAArticle: 45611
Xilinx has Flash memories, that can be used in the JTAG chain and can be programmed with the Parallel cable. XC18V04 for example. If you prefer to use other flash memories and want to programm them in-system, you will have to use the download cable of the flash manufacturer. You will also need glue logic to configure a Virtex-II out of a standard flash. -Manfred "ndesi" <ndesi@talk21.com> schrieb im Newsbeitrag news:cf531019.0207271342.22447b3f@posting.google.com... > Hello :) > > I want to configure my Virtex II parts with FLASH (Atmel or Intel). > I found app note how to do that > But question is How to Programm FLASH?? > > I am thinking of using CPLD and CPLD Logic convert "Xilinx Parallel > cable III" output to program FLASH > > Is it possible?? > Any other Idea?? > > I want to use Xilinx software and their cable but i can add only CPLD > to my board. > > Thanks In AdvanceArticle: 45612
Xilinx Virtex-II has DES encryption. Even if someone manages it to get the configuration bitstream, it is useless without the (secret) keys. -ManfredArticle: 45613
If the flash has jtag you can use the Xilinx cable III. The Xilinx tools won't do it for you but you can write your own tools from scratch. You can also download our HOTMan app builder software, which contains functions to help program jtag, and with a little programming you'll be able to program your device over the network if you want. Steve www.vcc.com "ndesi" <ndesi@talk21.com> wrote in message news:cf531019.0207271342.22447b3f@posting.google.com... > Hello :) > > I want to configure my Virtex II parts with FLASH (Atmel or Intel). > I found app note how to do that > But question is How to Programm FLASH?? > > I am thinking of using CPLD and CPLD Logic convert "Xilinx Parallel > cable III" output to program FLASH > > Is it possible?? > Any other Idea?? > > I want to use Xilinx software and their cable but i can add only CPLD > to my board. > > Thanks In AdvanceArticle: 45614
Simon, That's a bit of overkill isn't? Ranks right up there with Xilinx's rad-hard solution. :) If you want the cheapest, most secure programmable solution antifuse (Actel) is the way to go. No need for backup batteries, or any other "special" components. You, Cesar, and I should get together for some drinks one nite... Tim Sloper Field Applications Engineer (Actel) "S. Ramirez" <sramirez@cfl.rr.com> wrote in message news:fzb19.25216$s8.673318@twister.tampabay.rr.com... > > "Thomas Wollinger" <wollinger@crypto.ruhr-uni-bochum.de> wrote in message > news:ai2om4$10v3kt$1@ID-137468.news.dfncis.de... > > Hi everybody, > > > > I am looking for a FPGA that I have to use in a secure manner. I have to > do > > a project in which the FPGA is use in a 'military' like environment. > > > > Can somebody tell me which vendors and FPGA families are out there with > > 'special' security features? and which security features that are and what > > are they good for? > > > > The FPGA can use any technology (SRAM, antifues, flash ...), but it has to > > be secure against as much attacks as possible. > > > > Thanks everybody for your time. > > > > I really appreciate your help > > > > Thomas > > How about putting an SRAM based FPGA on a special battery circuit such that > it stays configured when power is off. That way when someone tries to break > into it, it loses configuration and all info is gone. You can make it such > that when the product cover is removed, power is removed from the FPGA. Any > SRAM FPGA will suffice, but Xilinx comes to mind! > > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA > >Article: 45615
Hi all,
I have this very small vhdl segment, I try to put in a 95144xl cpld.
Using ISE4.2, XST.
The problem I "suspect" is, that the "d" bus doesn't go tristate,
even when "rstout" is not active. What am I missing ?
thanks,
emanuel
P.S. "suspect" means, that some chip on the bus is blocking the bus.
And there are only three chips on it.
----------cut ------------------
library IEEE;
use IEEE.std_logic_1164.all;
entity cpld is
port (
rstout: in STD_LOGIC; -- enable signal
d: out STD_LOGIC_VECTOR(15 downto 0); -- databus
);
end cpld;
architecture cpld_arch of cpld is
begin
d <= B"1110_1100_1110_0111" when rstout = '0' else "ZZZZZZZZZZZZZZZZ";
end cpld_arch;
Article: 45616In article <eId19.43143$ND5.4382552@e3500-atl2.usenetserver.com>, Timothy R. Sloper <trs74@bellsouth.net> wrote: >Simon, > >That's a bit of overkill isn't? Ranks right up there with Xilinx's rad-hard >solution. :) If you want the cheapest, most secure programmable solution >antifuse (Actel) is the way to go. No need for backup batteries, or any >other "special" components. Actually, it may seem overkill, but it is of a greater level of security, since antifuses are easier to reverse engineer and extract the information than SRAM cells. Then again, it costs more. So much of security consists of determining what level of attack you are willing to stop, and stoping everyting up to that point, without going beyond it. So, to the origional poster, what are the ACTUAL security concerns desired? -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 45617
Nicholas, 1) There is absolutely no bit stream to intercept in an anitfuse scenario. 2) With the security bit set there is aboslutely no visibility into an anti-fuse part (this is permanent) 3) Reverse engineering antifuse FPGAs is an almost impossible task. In fact it's more difficult to reverse engineer an antifuse FPGA than most ASICs as the shorts between the metal lines are not visible from the top. To physical view the shorts you need to cross-section the device not look at it from the top. 4) It would be a painstaking process to determine the state of one switch element let alone the potentially millions of elements that are found in the larger devices to reproduce the entire design. Here is a link to an app note on security of anti-fuse and Flash devices http://www.actel.com/appnotes/DesignSecurity.pdf if anyone would like more detail. Tim "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message news:ai3qgd$1jd6$1@agate.berkeley.edu... > In article <eId19.43143$ND5.4382552@e3500-atl2.usenetserver.com>, > Timothy R. Sloper <trs74@bellsouth.net> wrote: > >Simon, > > > >That's a bit of overkill isn't? Ranks right up there with Xilinx's rad-hard > >solution. :) If you want the cheapest, most secure programmable solution > >antifuse (Actel) is the way to go. No need for backup batteries, or any > >other "special" components. > > Actually, it may seem overkill, but it is of a greater level of > security, since antifuses are easier to reverse engineer and extract > the information than SRAM cells. > > Then again, it costs more. So much of security consists of > determining what level of attack you are willing to stop, and stoping > everyting up to that point, without going beyond it. > > So, to the origional poster, what are the ACTUAL security concerns > desired? > -- > Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 45618
David R Brooks wrote:
> library work;
> configuration top_config of top is
> for struct
> for all : rstgenr
> use entity work.rstgenr(rtl);
> end for;
> ...
>
> Can anyone say how one should compile configurations in ISE?
I don't know about ISE, but leonardo can handle a top configuration
only if it is at the end of the last item in the file list
AND if the preceding file list is complete and in correct
compilation order.
-- Mike Treseler
Article: 45619
We've used the battery backed Xilinx solution before (in our case it was mission
equipment that got a download before the mission, and remained powered up until
the mission was complete). It does indeed offer more security than the anitfuse
because the bitstream is not present anywhere on the board except in the
programmed FPGA. Once power is removed, there is nothing to recover (well there
may be some residual charges on the gates that are even harder to detect and
reverse engineer than the anitfuses).
The battery maintained SRAM based gives you a couple advantages over the
anitfuse for this scenario: 1) you retain the flexibility of an FPGA, which
helps tremdously in minimizing inventory, putting in upgrades, and testability.
With the Antifuse, it may as well be an ASIC once it is programmed, 2) and more
significantly, you have the advanced features of the xilinx FPGAs available,
which make DSP applications in a single chip possible, specifically the fast
carry chains for fast, compact arithmetic and the distributed memory which is
used for compact delay queues which occur very frequently in DSP applications
(eg filters). The big disadvantage is that if the configuration is lost, the
module has to be returned for service. It can't be revived without an external
source of bitstream.
Like the Antifuse, the readback can be disabled on an SRAM FPGA making so the
bitstream cannot be read out of the device, and the device is complex enough
that even if it could, the reverse engineering effort would be substantial.
Still in either case, extreme methods could be used to recover the
configuration. The question comes down to what level of protection raises the
price of reverse engineering to the point where it is not worth attacking it?
The Antifuse does have an advantage in radiation hardness, which is exactly
where these devices have carved their greatest niche.
"Timothy R. Sloper" wrote:
> Nicholas,
>
> 1) There is absolutely no bit stream to intercept in an anitfuse scenario.
> 2) With the security bit set there is aboslutely no visibility into an
> anti-fuse part (this is permanent)
> 3) Reverse engineering antifuse FPGAs is an almost impossible task. In fact
> it's more difficult to reverse engineer an antifuse FPGA than most ASICs as
> the shorts between the metal lines are not visible from the top. To physical
> view the shorts you need to cross-section the device not look at it from the
> top.
> 4) It would be a painstaking process to determine the state of one switch
> element let alone the potentially millions of elements that are found in the
> larger devices to reproduce the entire design.
>
> Here is a link to an app note on security of anti-fuse and Flash devices
> http://www.actel.com/appnotes/DesignSecurity.pdf if anyone would like more
> detail.
>
> Tim
>
> "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
> news:ai3qgd$1jd6$1@agate.berkeley.edu...
> > In article <eId19.43143$ND5.4382552@e3500-atl2.usenetserver.com>,
> > Timothy R. Sloper <trs74@bellsouth.net> wrote:
> > >Simon,
> > >
> > >That's a bit of overkill isn't? Ranks right up there with Xilinx's
> rad-hard
> > >solution. :) If you want the cheapest, most secure programmable solution
> > >antifuse (Actel) is the way to go. No need for backup batteries, or any
> > >other "special" components.
> >
> > Actually, it may seem overkill, but it is of a greater level of
> > security, since antifuses are easier to reverse engineer and extract
> > the information than SRAM cells.
> >
> > Then again, it costs more. So much of security consists of
> > determining what level of attack you are willing to stop, and stoping
> > everyting up to that point, without going beyond it.
> >
> > So, to the origional poster, what are the ACTUAL security concerns
> > desired?
> > --
> > Nicholas C. Weaver nweaver@cs.berkeley.edu
--
--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: 45620It is a high barrier to reverse engineering, but arguably less than the battery configuration power supply or Virtex encrypted bitfile loader style. It's how much security at how much flexibility and cost that always needs to be kept in mind. In article <r%e19.43877$ND5.4403512@e3500-atl2.usenetserver.com>, Timothy R. Sloper <trs74@bellsouth.net> wrote: >1) There is absolutely no bit stream to intercept in an anitfuse scenario. There is absolutely no bitstream to intercept in the SRAM battery backup scenario. There is only a 3DES encrypted bitstream to intercept in the Virtex 2 encrypted bitfile setup. You want to brute force 3DES, be my guest. Considering the low power drain on the dedicated pins and the lifespan of Li batteries, the Virtex 2 style is fairly easy to use for most purposes. >2) With the security bit set there is aboslutely no visibility into an >anti-fuse part (this is permanent) A good probe technique should be able to create a break on the security bits, probably more reliabily than a glitch attack on the SRAM based security bits. That would be how I'd attack an antifuse setup: Reverse engineer the part until I can determine the location of the readback lock bits, then changed them by very fine drilling, probing, and filling. Basically drill down to where I need to break [1], backfill with insulator and conductor to restore any layers/vias broken on the way in, and then use the readback mechanisms. It is a damn challange (you go through a lot of basic parts), but still probably easier than attacking the SRAM based key approach (hit with hard radiation, probe for the bit states, use that as the seed number for a 3DES search, searching all keys which are a given hamming distance from my initial guess determined by probing). >3) Reverse engineering antifuse FPGAs is an almost impossible task. In fact >it's more difficult to reverse engineer an antifuse FPGA than most ASICs as >the shorts between the metal lines are not visible from the top. To physical >view the shorts you need to cross-section the device not look at it from the >top. Reverse engineering the state of battery backed SRAM is even harder, because of the probabilistic nature when you try to freeze the bits into a configuration and then probe them and probabilistically reconstruct the state, or live probing on the powered part. >"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message >news:ai3qgd$1jd6$1@agate.berkeley.edu... >> Actually, it may seem overkill, but it is of a greater level of >> security, since antifuses are easier to reverse engineer and extract >> the information than SRAM cells. >> >> Then again, it costs more. So much of security consists of >> determining what level of attack you are willing to stop, and stoping >> everyting up to that point, without going beyond it. [1] Since the antifuse operation is a closing operation, any break would be an opening. Since I can work on the part unpowered, it should be possible to drill through conducting layers and then reconstruct the layers after performing the breaks. Admittedly a very high barrier, but doable. This also works for EEPROM/flash, as it can create a short as well as a break. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 45621
Yes, Ray i agree with you, the input data should be sign extended.[ i have wriiten my query in hurry ;-)] staying in the same scheme serial digit input, serial digit output should sign extend the input data when using digit serial arithmetic Ray Andraka <ray@andraka.com> wrote in message news:<3D453FB4.6C6CF807@andraka.com>... > You are only partially correct. The input words need to be sign extended > rather than zero extended unless the input data is unsinged data (usually > not the case except in video). The wordlength only has to be extended if > the architecture of your fiter requires it. Scaling accumulator > multipliers, for example have a serial input and a parallel output, so the > serial input does not have to be extended at all. A serial distributed > arithmetic filter uses scaling accumulators to do the multiply, so you avoid > the need for input extension because the partial sums are accumulated as > parallel arithmetic. Only the partial sums are computed serially. See the > distributed arithmetic and multiplier pages on my website for a more > complete explanation. > > hristo wrote: > > > hello, > > may be basic question > > if someone has to implement an FIR using bit serial, he has to see the > > output wordlength, thus the FIR bit growth. Then, he needs to expand the > > input data with zero to have regular wordlength through the structure > > > > in parrallel we have not to do that > > > > what about digit serial, should we still need to expand the input data > > with zero digits > > > > Many thanks > > -- > --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, 1759Article: 45622
Paranoia !
I just thought I would check again the risc5x code I posted earlier works
correctly.
Looking with FPGA Editor it does build a single 8 lut long carry chain and
the 4.2i tools correctly strips off the DC carry bit, in my case using the
YB slice output.
Phew !
Mikej
"Ray Andraka" <ray@andraka.com> wrote in message
news:3D4541C8.FF7AC8B6@andraka.com...
> It may very well be tapping it. The virtex architecture supports tapping
the carry chain
> and sending it out the XB and YB outputs of the slice. I have had trouble
in the past
> getting the software to use that tap when the carry out to the next slice
is also used,
> although I don't recall if it was a xilinx problem or a synplify problem.
If you are
> using 4.x there is a good possibility that it is properly tapping the
carry chain. If you
> are using the paid version of the Xilinx software, you can open the FPGA
editor and
> examine the results directly. If not, you can tell from the timing report
if you have it
> show all timing and then you find the carry chain in question.
>
> Dmitri Katchalov wrote:
>
> > Thanks again everyone.
> >
> > Using your suggestions I've managed to implement PIC-style
> > ADD/SUB/INC/DEC with carry and half-carry out in just 4 slices, see code
below.
> > I'm not sure about the polarity of the borrow bit though.
> >
> > Synthesis infers 2 5-bit adders, later optimised into 4-bit
> > adders with carry in/out. P&R places them in one column one immediately
> > on top of another (in otherwise empty FPGA). I don't have suffucient
> > knowledge to tell from all those the reports whether the carry chain
> > is broken or continues over. It does seem to continue over.
> >
> > Here is the code, comments appreciated.
> >
> > Regards,
> > Dmitri
> >
> > library IEEE;
> > use IEEE.STD_LOGIC_1164.ALL;
> > use IEEE.NUMERIC_STD.ALL;
> >
> > entity alu_adder is
> > Port ( A,B: in std_logic_vector(7 downto 0);
> > op: in std_logic_vector(1 downto 0);
> > Y: out std_logic_vector(7 downto 0);
> > carry_out: out std_logic;
> > dc_out: out std_logic );
> > constant ADD : std_logic_vector(1 downto 0) := "00";
> > constant SUB : std_logic_vector(1 downto 0) := "01";
> > constant DEC : std_logic_vector(1 downto 0) := "10";
> > constant INC : std_logic_vector(1 downto 0) := "11";
> > end entity alu_adder;
> >
> > architecture Behavioral of alu_adder is
> > begin
> > process( A, B, op )
> > variable tmp: std_logic_vector(7 downto 0);
> > variable lo_nibble, hi_nibble: unsigned(5 downto 0);
> > variable cin: std_logic;
> > begin
> > case op is
> > when INC => tmp := (others => '0'); cin := '1';
> > when DEC => tmp := (others => '1'); cin := '0';
> > when SUB => tmp := not B; cin := '1';
> > when ADD => tmp := B; cin := '0';
> > when others => tmp := (others => '-'); cin := '-';
> > end case;
> >
> > lo_nibble := unsigned('0' & A(3 downto 0) & cin ) +
> > unsigned('0' & tmp(3 downto 0) & cin );
> >
> > hi_nibble := unsigned('0' & A(7 downto 4) & lo_nibble(5) ) +
> > unsigned('0' & tmp(7 downto 4) & lo_nibble(5) );
> >
> > Y <= std_logic_vector( hi_nibble(4 downto 1) & lo_nibble(4 downto
1));
> > dc_out <= lo_nibble(5);
> > carry_out <= hi_nibble(5);
> > end process;
> > end architecture Behavioral;
> >
> > Ray Andraka <ray@andraka.com> wrote in message
news:<3D43FE74.BC6780AD@andraka.com>...
> > > In order to tap the carry chain you need to add an extra bit in the
carry
> > > chain. The synthesis tools won't do that for you, and in fact will
not
> > > infer a caryy chain for less than about 7 bits. Using 2 four bit
counters
> > > you incur the delay to get off and then onto the second chain, where
with a
> > > single chain you only incur ~100ps. With 2 4 bit counts, it is likely
not
> > > your worst case path anyway, so for the sake of simplicity,
readability and
> > > maintainability of the code, it is probably better to just infer them
as
> > > separate counters. My point was that what you asked about could be
done,
> > > but it is not done automatically by the tools and it takes a bit of
> > > finabling to make it work.
> > >
> > > Eric Smith wrote:
> > >
> > > > > * How do I get the half-carry bit out of the 8bit adder? I guess I
can
> > > > > instantiate/infer two separate 4bit adders. Is there a better way?
> > > >
> > > > Ray Andraka <ray@andraka.com> writes:
> > > > > It can be done, but it takes a little mind-bending. Basically,
you
> > > > > need to turn your 8 bit adder into a 9 bit one with bit 4 being a
> > > > > dummy so that you can pull out the carry out through the bit. It
> > > > > takes a bit of caressing the tools to make them infer it.
> > > >
> > > > Is there any advantage to doing that rather than two four-bit
adders?
> > > > For instance, with two four-bit adders, does the synthesizer not
> > > > recognize that it can continue the carry chain between them? Or
> > > > does the FPGA not allow you to tap the carry from intermediate
stages
> > > > of the chain?
>
> --
> --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: 45623SAVE THE MUX F5 !!! I use them all the time ! 8 : 1 mux in 1 CLB (virtex E) : 4 LUT4, 2 F5s 1 F6 perfect ! you can (and we do) have chips full of these things. Mikej "John_H" <johnhandwork@mail.com> wrote in message news:3D416B70.B7E579BD@mail.com... > I love my F5 muxes! Synplify does a decent job of inferring them (less > common in general logic, more common in multiplexers). It's nice to have a > decode of the form register[index[2:0]] and get it all into one CLB with > some MUXF5 and MUXF6 elements. Bigger multiplexers just use more than one > stage of these. Heck, in the Virtex type parts I instantiate a "rotator" > that uses cross-coupled F6 muxes to give me a barrel rotate kind of > functionality with (more than) twice the efficiency of the standard > multiplexers alone. I'm just a little sad the Virtex-II doesn't > cross-couple the MUXF6 elements - I have to use a MUXF8 to use that same > technique! Less efficiency overall. > > Ahhh, esoteric design techniques . . . turning a 64 bit barrel shifter from > 192 slices to about 66 with one fewer levels of logic. Not for everyone but > fun for many. > > - John_H > MUXFn afficionado > > > Kevin Brace wrote: > > > I suppose, when BX or BY input is tied to a FF, it looks like to me you > > won't be able to use an F5MUX (A multiplexer that ties two 4-input LUTs > > to recreate a 4:1 MUX or a 5-input LUT.), but since most synthesis tools > > cannot seem to take advantage of F5MUX anyway, that shouldn't be a huge > > penalty. > > I do wonder, does anyone use F5MUX? > > Perhaps, shouldn't Xilinx get rid of it? >Article: 45624
If the buskeepers are enabled (default), the last state is held in tristate. MIKE "emanuel stiebler" <emu@ecubics.com> schrieb im Newsbeitrag news:3D456B80.A4455AC9@ecubics.com... > Hi all, > > I have this very small vhdl segment, I try to put in a 95144xl cpld. > Using ISE4.2, XST. > > The problem I "suspect" is, that the "d" bus doesn't go tristate, > even when "rstout" is not active. What am I missing ? > > thanks, > emanuel > > P.S. "suspect" means, that some chip on the bus is blocking the bus. > And there are only three chips on it. > > ----------cut ------------------ > > library IEEE; > use IEEE.std_logic_1164.all; > > entity cpld is > port ( > rstout: in STD_LOGIC; -- enable signal > d: out STD_LOGIC_VECTOR(15 downto 0); -- databus > ); > end cpld; > > architecture cpld_arch of cpld is > > begin > d <= B"1110_1100_1110_0111" when rstout = '0' else "ZZZZZZZZZZZZZZZZ"; > end cpld_arch;
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