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
Is that a Spartan-II or a SpartanXL board your selling? Yes, that's a real EMail address. On Thu, 6 Jun 2002 03:36:43 -0400, "Dan" <daniel.deconinck@sympatico.ca> wrote: >Hi Greg, > >You can program the Insight SpartanII with X-Checker or MultiLinx. > >My board is for sale for 50% off. Are you interested ? > >Sincerely >Daniel DeConinck >www.PixelSmart.com >TEL: 416-248-4473 > > >Article: 43951
On 7 Jun 2002 05:17:05 GMT, Steve Meyer <sjmeyer@www.tdl.com> wrote: > This may be a side effect of commercialization of Computer Science, > but there is a very interesting scientific puzzle that one can observe > at next week's Design Automation Conference (DAC). Namely, that although > formal verification has been a degenerating research program since at > least 1972, nearly every technical paper and new exhibitor is describing > tools for formal verification of circuits. Define 'degenerating' because I have no idea what you're trying to say. Please - I'm genuinely puzzled by what you said. I know a few people making their living quite nicely doing formal methods in academia, government, and industry. What part of FM is degenerating? > These tools supposedly lead to RTL sign off without a need to simulate and > verification usally by software checking of user supplied constraints. I've never heard *any* formal methods person advocate not simulating the RTL. Maybe I've not travelled in the same circles you have. All you get from FM is confidence that two representations of your circuit (your spec and your implementation) have some relationship (equivalency, implication). That certainly doesn't prevent your synthesis tool from breaking your design, or your layout tool, or the fab house. I like simulating the RTL as much to have confidence in my formal specs as to gain trust in my design. > Here are Some of the puzzles. 1) because formal proving is related to > BDD construction from net lists, this formal analysis should be usable > in communication code breaking cryptography. Yet, paper at this year's > Eurocrypt showed heuristics for the related NP complete problem do not help. > Reference is: Krause, M. "BDD-based Cryptanalysis of Keystream Generators", > Proceeding 2002 Eurocrypt, Springer, 2002. Also the objections to > formal verification first detailed in the Lighthill Report submitted to > the British Government in 1972 still need answers. I think you need to get out and look at formal methods more. I'm from the theorem prover side of the house (as opposed to the BDD side) and it's not a problem to omit BDDs entirely if you don't mind algebraic representations. I haven't read the paper you've cited, but I gave a lot of thought to crypto applications when I was in grad school. Feel free to ignore this: As to why BDDs aren't much use for crypto, the answer isn't hard: BDDs only have huge gains when the logic functions collapse nicely under a certain ordering of the logic variables. A big random function of 128 variables probably won't become tractable just because you throw BDDs at it. Luckily, most of the sorts of functions that real-life hardware designers use are much more amenable to BDDs, given a suitable variable ordering. Crypto functions are generally designed to mix up the variables quite completely, making the functions hard to manipulate algebraically (via theorem provers) or via BDDs. As to the 1972 paper, I'd have to go find it. The earliest FM-for-hardware papers I've studied are the RSRE Viper project from the mid 1980s. Is the Lighthill Report online? > Some are: 1) how is > correctness of human coded assertions verified, i.e. errors in assertions > become injected into formally verified circuits?, The problem of writing 'correct' specifications is, IMHO, harder than the problem of showing that a given design meets the specification. Joe Jackson said is succintly: you can't get what you want 'till you know what you want. The best ways I've found for writing good specs is lots of peer review together with use-case analysis; simulators also help a lot. Wwriting specs for hardware isn't much different than writing specs for software. Excepting those damn-near unreadable temporal logic specs, of course. Those are the specification equivalent to apl - write only. > 2) how can circuit proving > data structures not have exponential size? Here are two ideas: a) BDDs may reduce ugly logic equations to a more compact form, under certain ordering of the variables. See McMillan's "Symbolic Model Checking", or any BDD reference. I say 'may' because there are worst-case functions that are not amenable to BDDs. Fortunately, those sorts of functions are rare in most hardware designs, although crypto hardware is a notable exception. b) if you maintain the function symbolically, and do your verification that way, you may avoid exponential size at the expense of doing a big proof instead. If you do a brute-force case-analysis on the variables, of course you'll get an exponential number of proof cases. But the power of the proof tools is being able to perform induction or otherwise make the proof tractible. > 3) how can verification work > when the same formal algorithms are used to synthesize circuit in one > direction and verify them in other direction using same "closed system" > algorithms. I think you're confused here. Every formal verification tool I've seen attempts to show equivalence (or at least implication) of two different formalisms. For example, between a formal specification written in some logic (be it a temporal logic, or higher-order logic, or even propositional logic) and an implementation represented as a state machine, or BDDs, or some other representation. The benefit lies in showing that the implementation satisfies the spec. The equivalence checking folks make their money (or used to, anyway) by showing the equivalence of two diffenent forms of the implementation, as when the design is revved for other bug fixing. The formal checking takes less time than running a complete regression simulation, hopefully. > It is unfortunate that DAC technical committee does not try to balance > papers that advocate theories with papers that falsify theories. No one declared DAC the end-all and be-all of formal methods. If you've got some interesting results to present to the world, you've already found Usenet. Matt Drudge broke the Monica Lewinsky fiasco on his web site - I would assume that you could create a web page on which to publish your results. If you're just bent because DAC rejected your paper, get over it. The papers of many people are rejected from DAC - they've got finite space and time considerations. You're actually in good company. > In any > case, what is probably the most one side scientific refereeing in the last > 500 years should make for interesting listening and observing. I think you *might* be over-reacting just a smidge to having your paper rejected. 500 years of history goes back to 1502. Do you really believe DAC 2002 is the most one-sided scientific event in all that time? So what's the kernel of your gripe with formal methods? It sounds like you're convinced that FM is totally bogus. I think it's merely a pain in the butt, expensive, and arcane. But with ICs having 50M transitors and development schedules under 12 months, FM starts making sense compared to the concept of thousands of workstations running simulations 24/7. KellyArticle: 43952
> Since LS-Altera is free (Albeit the GUI is buggy.) even for QII Web > Edition users (Although I rather get a free crippled ModelSim instead.), > there really is no reason to use Quartus II native synthesis tool at all > other than maybe some beginners may appreciate it because they won't > have to import an EDIF netlist from LS-Altera. I echo the sentiment NOT to use quartus for synthesis, just place and route with the edif output from leonardo. If you use the buggy (but useable) gui you can even do the quartus place and route from within Leo. I would however use Q2 to generate PAR constraints as you can get more detailed than using Leo alone. I'm still using Leo 2001_1d, anyone any comments on the newest release?Article: 43953
John, I think I have enough info now! I will try it out when I come to implement in a couple of weeks... Thanks for your detailed help, Ken "John_H" <johnhandwork@mail.com> wrote in message news:3CFF8535.C8507535@mail.com... > If you're generating both clocks, the absolute best way is to run the whole > design at 100MHz and only clock in the 25 MHz every fourth clock. No CLKDLL > needed! > > always @(posedge clk100) > begin > // 1-of-4 pulse generator gives clean clkEna pulses > Gate25[3:0] <= |Gate25[2:0] ? Gate25 <<1 : 4'h1; > // The ena can be synthesized into logic or into the ena pin on and FDE > if( Gate25[3] ) Data25MHz <= Data25MHzIn; > end > > If the 25MHz section wants 40ns for the logic rather than 10ns as suggested by > the 100MHz clock, you can apply multi-cycle path timing consstraints to allow > the full 40ns cycle for the Xilinx place and route. > > > > Otherwise, if your direction is only 25MHz to 100MHz domain, choosing the 270 > phase for your 100MHz clock will give you 7.5 ns for the transition between the > two domains. If you go back to the 25MHz domain this would result in only 2.5 > ns suggesting a 180 clock for 5ns on each side might be better. > > I think the DLLs like the 0 phase feedback. >Article: 43954
Hi, This is a easy newbie question (I'm asking this as, up until now, I have just been concerned with designing and not programming!). Anyway, am using a Spartan II and will use an XC18V02 PROM. When I power-up, does the PROM begin to program the FPGA immediately after the power levels are stable? adrianArticle: 43955
Look on Motorolla web site. They have own implementation of PowerPC cpu. Best regards ,Vladislav Laurent Gauch wrote: > Hi all, > > Do you know a good book on the PowerPC architecture (with OPB LPB > arbitrer description)! > > (for introducing my students) > > LaurentArticle: 43956
Hi,
I am simulating a design which uses an SRL16 primitive from the unisims
library.
Every 9th clock cycle or so, I get an 'X' on the Q output.
The design is fully synchronous. There are no 'X's on the inputs and
the 'A0' - 'A3' inputs are tied to '1'.
Any ideas what's going on?
Does it have something to do with the way the shift register is defined
in the 'unisim_VITAL.vhd' library ('16 downto 0' is 17 bits!)?
signal SHIFT_REG : std_logic_vector (16 downto 0) := ('X' &
To_StdLogicVector(INIT));
Cheers,
--
. . Iain Waugh
. o ._o .o \#/. o. o_. o . iain@zip.com.au
`) /\ =) .-kai- )= /\ )' http://www.zip.com.au/~iain
/< < < /#\ . > > >\ :.::.:TAG.:.::.
.
Article: 43957Mr. Lesea, recently you wrote: (excerpt from your white paper pre-release) > > In Virtex II and Virtex II Pro, low threshold (Vt) NMOS transistors are used to > buffer the outputs of the pass gate multiplexers. The low Vt NMOS transistors are > leakier than the higher threshold PMOS transistors. Choosing a logic high as the > “normal” or “static” state (e.g. using inverted sense logic signal states) causes > the NMOS to be ON, and the PMOS to be OFF, which exhibits less power than the other > way around. In one of your following answers you replied to a colleague of mine: > If there are low Vt nmos transistors (in the interconnect), they have more leakage if the > outputs are '1' than if they are at '0'. Depending on where these are used, theystate of > the logic will determine the output condition. I just want to ask if a figure will be included in the white paper describing the structure you are talking above? (I recognise that drawing an ASCII figure here in the newsgroup is somewhat cumbersome ...) I'd like to follow the train of thoughts - that' s the reason I encourage you to add some details. Where does the leakage current goes through? What is its path? Thanks, GuidoArticle: 43958
> Anyway, am using a Spartan II and will use an XC18V02 PROM. When I power-up, > does the PROM begin to program the FPGA immediately after the power levels > are stable? > > adrian Adrian, you might want to look up "mode pins" or something in Xilinx's SpartanII documentation. Whether or not the prom starts to load "immediately" depends on how you wire those pins. /HTH, Torbjörn StaboArticle: 43959
cfk <cfk_alter_ego@pacbell.net> wrote: > I innocently added NET "PCICLK" IOSTANDARD="PCI33_3" to my UCF file. To my > surprise, there was no difference in the ringing and overshoot. I tried > making it a syntax error to convince myself that this file really was being > read by the ISE software and yes it is. So, I guess one of two things is The tools are notoriously bad for ignoring incorrect IOSTANDARDs. Generally, these get changed back to LVTTL, and only MAP with the detailed report enabled will even tell you that it occurred. The IOSTANDARDs are case sensitive too! (from memory). Check the pad report in the PAR log file (versions <= 4.1 only), or the MRP map report, or perhaps the PAD report. One of them has the IO standards actually used for each pin. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 43960
F.M. Fontaine <fontain@nlr.nl> wrote: > I think that XACTStep 6.0.1 (which actually is XACT 5.2.1) from november > 1996 is the last version to support the original XC2000/XC3000/XC4000 > families. > XACTStep 6.0.1. is a windows version (originally Win 3.11) which will run > under Win95, I don't know if it will run under NT, 98, ME, 2000 or XP. > XACT 5.2.1 is a DOS version of the same core-tools. > Both version require a dongle ... Most likely it will refuse to read the EDIF from modern synthesis tools too. EDIF version too new, from memory. Maybe I'm mistaken. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 43961
Rick <rickspxmgoaway@algor.co.uk> wrote: > it seemed like a good candidate for ``exact'' mode. This worked fine in > that it matched 100% of the components and 100% of the signals and PAR > finished in next to no time .... Unfortunately it totally failed to > routed any of the PWR/GND connections - even after a second attempt > using the re-entrant routing -k flag! > Anyone seen this problem ? it doesn't seem to be mentioned in the > answers database. > Trying again with ``leveraged'' mode lead to 370 comps that guided > placement failed to put back, ~5000 connections unrouted, an overall > routing time much greater than the first one [which had hit the timing > contraints in the first pass], and a small contsraint failure (32ps > total). Rick, are you using guided MAP as well as guided PAR? Guided MAP helps PAR to match placements in my experience. Hamish -- Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 43962
hamish@cloud.net.au wrote: > Rick <rickspxmgoaway@algor.co.uk> wrote: > > it seemed like a good candidate for ``exact'' mode. This worked fine in > > that it matched 100% of the components and 100% of the signals and PAR > > finished in next to no time .... Unfortunately it totally failed to > > routed any of the PWR/GND connections - even after a second attempt > > using the re-entrant routing -k flag! > > > Anyone seen this problem ? it doesn't seem to be mentioned in the > > answers database. > > > Trying again with ``leveraged'' mode lead to 370 comps that guided > > placement failed to put back, ~5000 connections unrouted, an overall > > routing time much greater than the first one [which had hit the timing > > contraints in the first pass], and a small contsraint failure (32ps > > total). > > Rick, are you using guided MAP as well as guided PAR? > Guided MAP helps PAR to match placements in my experience. > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> O.k. I'll give that a try - both ``exact'' & ``leveraged''.Article: 43963
hamish@cloud.net.au wrote: > F.M. Fontaine <fontain@nlr.nl> wrote: > > I think that XACTStep 6.0.1 (which actually is XACT 5.2.1) from november > > 1996 is the last version to support the original XC2000/XC3000/XC4000 > > families. > > XACTStep 6.0.1. is a windows version (originally Win 3.11) which will run > > under Win95, I don't know if it will run under NT, 98, ME, 2000 or XP. > > XACT 5.2.1 is a DOS version of the same core-tools. > > > Both version require a dongle ... > > Most likely it will refuse to read the EDIF from modern synthesis tools > too. EDIF version too new, from memory. Maybe I'm mistaken. > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au> May even be worse than that since my memory says that the XACT tool's native netlist format was XNF and EDIF didn't come in until the M1.X tools. BTW Anyone know just who was responsible for the choice/design of EDIF? The Lisp idiocy means it dismally and completely fails the most basic requirement of any EDA language or format - "Can it be parsed/hacked with Perl ?".Article: 43964
> Xilinx publishes two different software products: > > 1. Alliance > > It only has P&R tools. You must have a synthesizer program to generate > gate-level description out of a hardware programming language like VHDL, > Verilog. An example of synthesizer program is Synplicity's Synplify > (http://www.synplicity.com). Company name is Synplicity, product name is > Synplify. > > 2. Foundation > This is how it used to be. I am not sure whether P&R only package is still available, but the Foundation certainly is being phased out and replaced with the Xilinx ISE, which is a full design environment including synthesis, etc. Up to May 31st there was a choice of synthesis tool that one could use with it, either FPGA Express or Xilinx XST. As far as I understand the agreement between Xilinx and Synopsys is now over and new users can no longer purchase FPGA Express through Xilinx. -- ============================ Mikhail Matusov Hardware Design Engineer Square Peg Communications Tel.: 1 (613) 271-0044 ext.231 Fax: 1 (613) 271-3007 http://www.squarepeg.caArticle: 43965
Guido, I must refrain from getting into too many details, as the circuits vary from family to family, based on the available technolgies from our foundry partners. If you visit a foundry website (TSMC, UMC, IBM) you will see what the available process devices are for any given technology node (eg .13u). If you are interested in this topic, I sugggest you use the USPTO (US Patentent and Trade Mark Office) website, and search through the patents on the subject. As well, the Berkeley Wireless Center Research Group has a PhD Thesis posted on the subject. The use of low Vt transistors is commonly referred to as the "high speed" transistors, and microprocessor designers use them almost exclusively. I am sure that there is a lot of literature on this subject as well out there. To discuss the actual particulars of how the device is designed is something we consider proprietary and confidential. The information that I posted on power management is also in a paper that was given at a recent conference, and hence is also public knowledge. It is sufficent to say that if you have a choice of the logic state of signals, choosing logic high = true, or logic low = true may result in a small power savings at high temepratures due to the lowered leakage. If the signals are transistioning ~50% of the time, it makes no difference. Even in 0.13u, the leakage current is not much of a factor (say the way it is in a microprocessor, where as much as 50% of the power is DC leakage at hot). I hardly expect anyone to save any power by this means until we get to even smaller gate lengths. Austin Guido Pohl wrote: > Mr. Lesea, > > recently you wrote: (excerpt from your white paper pre-release) > > > > > In Virtex II and Virtex II Pro, low threshold (Vt) NMOS transistors are used to > > buffer the outputs of the pass gate multiplexers. The low Vt NMOS transistors are > > leakier than the higher threshold PMOS transistors. Choosing a logic high as the > > “normal” or “static” state (e.g. using inverted sense logic signal states) causes > > the NMOS to be ON, and the PMOS to be OFF, which exhibits less power than the other > > way around. > > In one of your following answers you replied to a colleague of mine: > > > If there are low Vt nmos transistors (in the interconnect), they have more leakage if the > > outputs are '1' than if they are at '0'. Depending on where these are used, theystate of > > the logic will determine the output condition. > > I just want to ask if a figure will be included in the white paper describing the structure you are talking above? > (I recognise that drawing an ASCII figure here in the newsgroup is somewhat cumbersome ...) > I'd like to follow the train of thoughts - that' s the reason I encourage you to add some details. Where does the leakage current goes > through? What is its path? > > Thanks, GuidoArticle: 43966
I have an well established VirtexE design (schematic) that uses a couple of LVDS inputs. All other I/O is 3.3v TTL. All the I/O Vcc pins are connected to 3.3v. No errors are reported, and the design has been in production and working for over a year. I now get a request to turn one of the LVDS pairs into an I/O so a non-time-critical LVDS signal (reset) can be driven by the fpga. When I make the changes, I get errors saying I have banking violations and that the bank with the LVDS output should be at 2.5v. When I make all other TTL I/O's in the bank LVCMOS2 instead of the default LVTTL my design compiles with out error, but it also assumes the bank will be at 2.5v. What will happen when this bank is connected to 3.3v? As stated before, timing on the LVDS output is not an issue. Thanks DanArticle: 43967
The simulation primitive might not be up to snuff. In my post P&R Verilog
simulations I had to replace the instances of X_SRL16E.v with my own
version to get around a bogus timing problem. Changing the file to add a
#2 (2 ps delay) in front of "{data[15:0} <= {data[14:0],d_in};" took care
of it for me. The problem may be the same in the VDHL simprim.
If you look into the simprim with your simulator you may find just where
the simprim decides the "X" is declared. The "notifier" in the Verilog was
the key element that gave me my X.
- John_H
Iain Waugh wrote:
> Hi,
>
> I am simulating a design which uses an SRL16 primitive from the unisims
> library.
>
> Every 9th clock cycle or so, I get an 'X' on the Q output.
>
> The design is fully synchronous. There are no 'X's on the inputs and
> the 'A0' - 'A3' inputs are tied to '1'.
>
> Any ideas what's going on?
>
> Does it have something to do with the way the shift register is defined
> in the 'unisim_VITAL.vhd' library ('16 downto 0' is 17 bits!)?
> signal SHIFT_REG : std_logic_vector (16 downto 0) := ('X' &
> To_StdLogicVector(INIT));
>
> Cheers,
> --
> . . Iain Waugh
> . o ._o .o \#/. o. o_. o . iain@zip.com.au
> `) /\ =) .-kai- )= /\ )' http://www.zip.com.au/~iain
> /< < < /#\ . > > >\ :.::.:TAG.:.::.
> .
Article: 43968
Hi Mr. Modderkolk,
try this, it detects rising and/or falling edges of your switch.
If you need more VHDL examples, just download
the examples of our Spartan-2 development boards
from www.cesys.com (go to download-section)
Have a nice day
Manfred Kraus
library IEEE;
use IEEE.std_logic_1164.all;
entity EdgeDetect is
port (
SCLK: in STD_LOGIC;
Reset: in STD_LOGIC;
Input: in STD_LOGIC;
O: out STD_LOGIC;
Rise: in STD_LOGIC;
Fall: in STD_LOGIC;
Enable: in STD_LOGIC
);
end EdgeDetect;
architecture EdgeDetect_arch of EdgeDetect is
signal OldValue: STD_LOGIC;
signal SyncIn: STD_LOGIC;
begin
SyncInput: process (SCLK, Input)
begin
if (SCLK = '1' AND SCLK'EVENT) then
SyncIn <= Input;
end if;
end process;
EdgeDetect: process (SCLK, RESET, OldValue, SyncIn)
begin
if (RESET = '1') then
O <= '0';
elsif (SCLK = '1' AND SCLK'EVENT) then
if (ENABLE = '1' AND RISE = '1' AND OldValue = '0' AND SyncIn = '1') OR
(ENABLE = '1' AND FALL = '1' AND OldValue = '1' AND SyncIn = '0')
then
O <= '1';
else
O <= '0';
end if;
end if;
end process;
process (SCLK, RESET, SyncIn)
begin
if (SCLK = '1' AND SCLK'EVENT) then
OldValue <= SyncIn;
end if;
end process;
end EdgeDetect_arch;
"F. Modderkolk" <frankmotje@hotmail.com> schrieb im Newsbeitrag
news:82eb64d2.0206032335.39c179aa@posting.google.com...
> If I test the vhdl code with modelsim, it works just fine, but when I
> implement it, it doesn't do anything. The function of the code is to
> create a puls with a lenght of one clockpuls when I push a button
>
> the code:
>
> library IEEE;
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
>
> entity startertwee is
> Port ( puls : in std_logic;
> pulsuit : out std_logic;
> clk : in std_logic;
> stopenreset : in std_logic);
> end startertwee;
>
> architecture Behavioral of startertwee is
> signal intern : std_logic;
> signal bpulsuit : std_logic;
>
> begin
> process (clk)
> begin
> if clk'event then
> if stopenreset = '1' then
> pulsuit <= '0';
> intern <= '0';
> bpulsuit <= '0';
> else
> if clk = '1' then
> if puls = '1' and intern = '0' then
> bpulsuit <= '1';
> intern <= '1';
> elsif puls = '0' and intern = '1' then
> intern <= '0';
> bpulsuit <= '0';
> else
> bpulsuit <= '0';
> intern <= intern;
> end if;
> end if;
>
> if clk = '0' then
> pulsuit <= bpulsuit;
> end if;
> end if;
> end if;
> end process;
> end Behavioral;
>
>
> Is there something I forget to program or something I do wrong?
> I hope you can help me
> thx
Article: 43969
The unisims SRL16 has a timingcheckson generic which you'll need to set to
false if you are simulating this with RTL level code, otherwise the delays will
cause it to clock data in wrong. It is possible that unknown data is getting
clocked in. The model has a 17 bit vector with the last one set to 'X' to
handle some of the special cases, don't worry about that.
If turning the timingchecks off doesn't fix you problem, it would be helpful if
you would post the snippet of code including the logic feeding the SRL16 so
that we could see what you are doing. Could be an RTL flip-flop that is not
initialized feeding into it too.
John_H wrote:
> The simulation primitive might not be up to snuff. In my post P&R Verilog
> simulations I had to replace the instances of X_SRL16E.v with my own
> version to get around a bogus timing problem. Changing the file to add a
> #2 (2 ps delay) in front of "{data[15:0} <= {data[14:0],d_in};" took care
> of it for me. The problem may be the same in the VDHL simprim.
>
> If you look into the simprim with your simulator you may find just where
> the simprim decides the "X" is declared. The "notifier" in the Verilog was
> the key element that gave me my X.
>
> - John_H
>
> Iain Waugh wrote:
>
> > Hi,
> >
> > I am simulating a design which uses an SRL16 primitive from the unisims
> > library.
> >
> > Every 9th clock cycle or so, I get an 'X' on the Q output.
> >
> > The design is fully synchronous. There are no 'X's on the inputs and
> > the 'A0' - 'A3' inputs are tied to '1'.
> >
> > Any ideas what's going on?
> >
> > Does it have something to do with the way the shift register is defined
> > in the 'unisim_VITAL.vhd' library ('16 downto 0' is 17 bits!)?
> > signal SHIFT_REG : std_logic_vector (16 downto 0) := ('X' &
> > To_StdLogicVector(INIT));
> >
> > Cheers,
> > --
> > . . Iain Waugh
> > . o ._o .o \#/. o. o_. o . iain@zip.com.au
> > `) /\ =) .-kai- )= /\ )' http://www.zip.com.au/~iain
> > /< < < /#\ . > > >\ :.::.:TAG.:.::.
> > .
--
--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: 43971I have to say that I looked with my scope and did not see any significant changes day before yesterday. Yesterday, I stored the clock waveform (I am trying to emit a PCICLK) with both LVTTL and PCI33_33 and compared the waveforms. It turns out that the IOSTANDARD was changing in a more subtle fashion then I was looking for. The gist of it is that the rise and fall times were changing with IOSTANDARD, but not the over/undershoot. So, I can say that IOSTANDARD was being set from the UCF file in ISE. It just turned out that I needed a 56ohm series resistor on my clock line to bring the over/undershoot back to reasonable. Thank you for your comment hamish, and I will study the PAR report. Charles <hamish@cloud.net.au> wrote in message news:3d00ba36$0$31828$afc38c87@news.optusnet.com.au... > cfk <cfk_alter_ego@pacbell.net> wrote: > > I innocently added NET "PCICLK" IOSTANDARD="PCI33_3" to my UCF file. To my > > surprise, there was no difference in the ringing and overshoot. I tried > > making it a syntax error to convince myself that this file really was being > > read by the ISE software and yes it is. So, I guess one of two things is > > The tools are notoriously bad for ignoring incorrect IOSTANDARDs. > Generally, these get changed back to LVTTL, and only MAP with the > detailed report enabled will even tell you that it occurred. The > IOSTANDARDs are case sensitive too! (from memory). > > Check the pad report in the PAR log file (versions <= 4.1 only), > or the MRP map report, or perhaps the PAD report. One of them > has the IO standards actually used for each pin. > > > Hamish > -- > Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>Article: 43972
Hi, I have done simple EPLDs with device like Altera EPM7064 and 10K Flex series. So far I have used AHDL. How difficult is it to do math functions such as axis transformations in an EPLD ? I am trying to find out whether it would be possible to use a smallish EPLD / FPGA such as a FLEX 10K10 or 10K20 to provide meaningfull acceleration of axis transformation done with an 8 bit processor. The calculations are done in floating point, and the slowest functions are the sin, cos functions. I would be greatfull for any input regarding this. Regards Anton ErasmusArticle: 43973
I need to implement a PCI interface in a VirtexE 2000 device. I have been studying the opencore PCI-Wishbone bridge and I can synthesize it in ISE and load the bitstream into my VirtexE. It turns out also in this project, that there is no motherboard with a PCI system controller, so I have implemented control of RST, a PCICLK generator (which now works after I fixed the rise/fall times and under/overshoot). I also have an arbiter module, so I am creating the system controller in the same Virtex. I have to say that I have seen mixed comments on the opencore PCI-Wishbone bridge, and yesterday, I attended a meeting where the subject of changing the PCI interface from PCI32/33 to PCI64/33 was discussed. That very well will send me towards LogiCORE as the PCI-Wishbone bridge is PCI32/33 only. I would appreciate a discussion of success or failure from others that have used the PCI-Wishbone bridge and also a discussion of the relative merits of the various Xilinx LogiCORE offerings. I see three varying in cost from $10K to $20K and quite frankly I cant see which should be picked. I also see mention of the fact that the IP seems to have significant strings attached to it, in that the bitstream needs to be downloaded from the so-called "Xpresso" cafe, and it doesnt appear that I may get to change the code for my custom, non-motherboard implementation. I thank you all in advance, CharlesArticle: 43974
Download a copy of my paper "A Survey of CORDIC algorithms for FPGA based
computers" from the publications page on my website. CORDIC is a
shift-add algorithm for rotating vectors in the X-Y plane, and can be
used for both R->P and P->R conversions, magnitude, simultaneous sine and
cosine and other functions. To handle floating point, you'll need a
complex normalize in front of it to weight both the I and Q the same and
some rescaling possibly at the output. A bit serial sequential machine
can be made pretty small, or you can go to a fully parallel architecture
if performance is your goal. I've done CORDIC rotators in Flex10K and
20K in the past.
Anton Erasmus wrote:
> Hi,
>
> I have done simple EPLDs with device like Altera EPM7064 and 10K Flex
> series. So far I have used AHDL.
> How difficult is it to do math functions such as axis transformations
> in an EPLD ? I am trying to find out whether it would be possible to
> use a smallish EPLD / FPGA such as a FLEX 10K10 or 10K20 to
> provide meaningfull acceleration of axis transformation done with
> an 8 bit processor. The calculations are done in floating point, and
> the slowest functions are the sin, cos functions.
> I would be greatfull for any input regarding this.
>
> Regards
> Anton Erasmus
--
--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
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