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
I always hated that the PCI cores were so heavily priced compared to the FPGA they might go into. The pricing seemed to reflect the value they once added to ASICs some 10 or 15 years ago and not the potential of really low cost low volume applications. A $100 FPGA in small vol applications doesn't support $20K IP for a few $ worth of fabric it uses. It might be a bargain compared to the cost of rolling your own though, just as buying an FPGA is a real bargain compared to rolling my own FPGA/ASIC too. FPGAs need lots of I/O to be useful, so why not put the damn IP in hard macro form and let everyone at it. And do the same again for PCIe (if thats possible?). We see how much more usefull FPGAs are with all the other stuff thats been added over the years, BlockRams, multipliers, clocks etc, but its really the IO where the sh1t hits the fan first. I would say that if we were to see PCIe on chip, even if on a higher $ part, we would quickly see alot more co pro board activity even just plain vanilla PC boards. I wonder if there were multiple built in narrow PCIe links whether they could be used to build node to node links ala HT for FPGA arrays? . Not that I really know much about PCIe yet. John Jakson transputer guyArticle: 101801
Andy wrote: > "Never" is a very strong word, and is almost never correct... > > Asynchronous reset inputs are perfectly safe to use, and often > necessary when circuit response must be guaranteed, even in the absence > of a clock. However, they must be used carefully, controlling the > release of reset (actually a synchronous event) such that it meets > setup and hold relative to the clock. > > What I recommend to resolve the release of reset problem is to > synchronously release (deassert) the reset signal tied to the async > reset inputs on the state registers. Note that the reset signal still > asserts asynchronously, it only deasserts synchronously. > > rst: process (rstin, clk) is > begin > if rstin = '1' then > rstmeta <= '1'; > rstout <= '1'; > elsif rising-edge(clk) then > rstmeta <= '0'; -- potentially metastable > rstout <= rstmeta; -- meta-rejected > end if; > end process; > > fsm: process (rstout, clk) is > begin > if rstout = '1' then > state <= reset_state; > elsif rising_edge(clk) then > case state is > ... > end if; > end process; > > Andy An important thing to remember is the 'others' clause in the case statement (missing from Andy's snippet above) that should always put the FSM to a default/reset state. Since FSM state registers are almost always one-hot encoded by FPGA synthesis tools, anytime it acquires an illegal value the FSM will be self-resetting thanks to such an 'others' clause. Regards, Alif.Article: 101802
David M. Palmer wrote: > In article <1146955848.154397.42440@i40g2000cwc.googlegroups.com>, > BoroToro <beiermann@gmail.com> wrote: > > >>I just received my Spartan 3e starter kit and had to share my >>frustration... >> >>The huge DRAM and the fast FPGA seem to make this board ideal for video >>and sound processing. But.. why on earth does the board come with a >>3bit VGA output? We do not live in the 80ies anymore. Adding a couple >>of resistors to get 8 or 12bit color resolution would hardly have >>changed the BOM. Even a video DAC is not expensive. > > > It would, however, have used up more IO pins. I don't know if that was > a consideration, but they do seem to share pins for the devices on the > SPI bus. > > Does anyone know if doing PWM on the VGA output pins would cause Bad > Things to happen to a typical monitor? It would have to be above the video clock rate, and then it would depend on the slew symmetry of the video amplifier. For a LCD monitor, it would be more unpredictable, as they sample the analog IP to create the digital drive signals. -jgArticle: 101803
Weng Tianxiang wrote: > Hi, > Recently I received a RFID chip to open company's door when entering > office building. > > It is very easy to carry and use like a key. > > I would like to know whether it contains a battary or not. > > If there is no battary in it, how can a circuit work running with Radio > Frequency? > > Weng Know how an AC power transformer works ? The power going in doesn't have to be a fixed frequency, it can be modulated a little. The secondary coil may have a switchable shunt across it. Combine them into a communications system. Increase the distance till they are quite separate and the secondary coil can be quite small and embedded on a Si chip as coils surrounding the chip or on a carrier pcb. Still power transmitted in the primary can reach to some degree the secondary and be rectified, stored and the local logic can both detect variations in the received power frequency (data input) and shunt the secondary coil (data output) and that can be detected by the power transmitter as changes in the impedance of the primary coil. Datarates of 1MBps or so even 20 years ago in close proximity. Well thats as I understood it 15yrs ago, I guess it finally cought on. I once developed the smart idea of storing music albums on a compressed ROM chip and using RF as the means to both power and read/play the music out. At the time the Rom would have only been 64MBits, 1GByte Flash & MP3 was more than a decade later.. This would have made the device contactless and fully protected from scratching etc unlike the CDs we still have today. John Jakson transputer guyArticle: 101804
Alot of good stuff there but not exactly drive by reading. So what would you call someone that hasn't pre wiki'ed up on something. If we all went to wikipedia first, we could dissolve the news groups right?Article: 101805
Hi, just a note that the FPGA boards bonus-sets offer is closing tonight around midnight. We are very happy that many people have taken up the great bonuses-offer so far. I'm excited that we will be able to deliver so many "goodies parcels" this week. There is a short time left to order your own "goodies parcel". If you order before the bonuses-site is taken down, you can still receive bonuses there worth AU$98.00 and AU$325.00. Not to mention the incredible 4-for-1 offer which is running concurrently. Please read all about it at http://www.burched.biz , where you will also see some e-books on a home-built laser cutter! :) Best regards, Tony Burch PS. You may need to press the refresh button on your web browser if you have looked at the site recently because it has been frequently updated.Article: 101806
Austin Lesea wrote: > But you must understand that > we can not support components purchased through non-authorized channels. That's great, certainly helps drive the prices down on Gray market parts, which means your customers eats their shirt when they need to resell excess inventory. :) (with some gleeful sarcasm and self interest)Article: 101807
the missing schmitt's shouldnt be a problem. But I still dont know what is the best and minimal hardware connection of the LED to the FPGA I first tried to use no components connection by connecting the LED directly to io pins and using pullup-down as resistor, but I got rather bad results for some reason, the light sensitivity was about 0.2% at the best (light dependant change of oscillating frequency) by using the R-C-R 3 pin oscillator from Peter Alfkes 'six easy pieces' I got 10% difference between sunlight and dark, setup R1=R2=18k C=10nf in series with green SMD LED dark 740 KHz light 670 Khz I havent looked at signal on the iopins at all, I guess there should be some better setup than using 3 io pins and 2 resistors to measure the LED as sensor Antti here is the RCR oscillator I used two resistors in series from ri to ro the middle of them via led in series with capacitor to c ------------ library ieee; use ieee.std_logic_1164.all; entity xti_oco_rcr is port ( ri : in std_logic; ro : inout std_logic; c : inout std_logic; en : in std_logic; -- always 1 clk : out std_logic); end; architecture rtl of xti_oco_rcr is signal c_s : std_logic; begin clk <= ri; ro <= not c when en='1' else 'Z'; c <= c_s when en='1' else 'Z'; c_s <= not (not ((not (not ri and not ro)) and c) and (not (ri and ro)) ); end rtl;Article: 101808
I have a little problem with flashing a led. I want flash a led for indicating the status of my program. I do the following: LED1 <= '1', '0' after 200 us; But it burn all the time. Do you have a solution? ( wthout counters)Article: 101809
Antti wrote: > the missing schmitt's shouldnt be a problem. > > But I still dont know what is the best and minimal hardware connection > of the LED to the FPGA > > I first tried to use no components connection by connecting the LED > directly to io pins and using > pullup-down as resistor, but I got rather bad results for some reason, > the light sensitivity was > about 0.2% at the best (light dependant change of oscillating > frequency) > > by using the R-C-R 3 pin oscillator from Peter Alfkes 'six easy pieces' > I got 10% difference > between sunlight and dark, setup > R1=R2=18k > C=10nf in series with green SMD LED > > dark 740 KHz > light 670 Khz That's an appx tau Equiv Cap of 80pF, so the LED is being some sort of Current Offset Varicap. No DC current can flow thru the 10nF. > I havent looked at signal on the iopins at all, I guess there should be > some better setup than using 3 io pins and 2 resistors to measure the > LED as sensor The LED will inject is a couple of uA, so a circuit needs to sense that. With a 3 term Osc, and DC current injection (not what you have above) DC current injection will first skew duty cycle before it really affects Freq much. Probably the best oscillator topology for dF with injection current sense, is to copy the HC4046 Oscillator. That is cross coupled S-R latch, with OC discharge, and the charge signal on one side, can be the LED current. This OSC can have either a single CAP, or two CAPs Very large dF with light can result, which can be damped with a parallel injection current. ( say 10M or 20M ) -jgArticle: 101810
Thomas Womack (twomack@chiark.greenend.org.uk) wrote: : I'm not sure that a hypertransport-attached CCD is very practical: HT : is a short-range interconnect, and I suspect it's fast enough that : you'd have great difficulty implementing it in the rather peculiar fab : processes required to make a CCD. : I can't find a datasheet for a modern CCD, but the obsolete TC237 : has only twelve pins, requires rather complicated digital waveforms : on five of them, and outputs analogue pixel data on two more; you : want to keep the ADC as close to the detector as possible, I'd have : thought connecting the ADCs via an FPGA to gigabit-ethernet channels Indeed. Most CCDs are analogue devices with external drivers for a reason - they need rapidly slewing clocks to read them out and very low noise amplifiers + ADCs to digitize the data. For sure gigabit eth or whatever serial protocal may be used, doesn't rally matter as long as the rate's high enough and the latency low enough - it'd just be nice if the opteron socketed FPGA and similar projets had serial transcievers to talk such high speed serial links :-) cdsArticle: 101811
Jep wrote: > I have a little problem with flashing a led. > > I want flash a led for indicating the status of my program. > > I do the following: > > LED1 <= '1', '0' after 200 us; > > But it burn all the time. > > Do you have a solution? ( wthout counters) faster eyes ? -jgArticle: 101812
Jeremy Ralph schrieb: > Thanks Falk, for the numbers. Any reason why AGP couldn't be used > for non-graphics streams? Non that I know of. Regards FalkArticle: 101813
Jep schrieb: > I have a little problem with flashing a led. > > I want flash a led for indicating the status of my program. > > I do the following: > > LED1 <= '1', '0' after 200 us; > > But it burn all the time. > > Do you have a solution? ( wthout counters) Whats wrong with a counter? You do know that the above statement is for simulation only and can not be synthesized in real hardware? Regards FalkArticle: 101814
Hi all. As part of my university studies, I am involved in a university project concerning the analysis and design of an 802.11a transceiver. For the first part of my work, I need to gather information regarding the base-band implementation of an OFDM modulator and demodulator with an FPGA. I was wondering if you can address me to some good documentation, in particular it would be nice to have a diagram / text with in-depth information on the blocks required, number of lines, available FPGA, etcetera. Anyway, any help will be much apreciated. Ciao, FrancoArticle: 101815
Jeremy,
> So let's say one was able to demo a 50% performance improvement for
> some specialized task using FPGA, custom RTL and HAL.
Then one can match that performance buying a faster CPU
or a multi-CPU board or a cluster of PCs. High-end FPGAs
are extremely expensive, low-end chips are not competitive,
so the final result of the analysis is "no", either because of
unacceptable price/performance factor or because of neglectable
performance improvement.
> Let's say the design is scalable such that with 8X FPGA gates
> I'd get a 8*50% performance improvement.
AFAIR a nice 2 GHz Sempron chip costs about $70. No FPGA can
beat its price/performance ratio if its tasks would be CPU-like. An FPGA
device can easily win with any general-purpose CPU in the domain of
DSP, advanced encryption and decryption, cipher breaking, true real-time
control etc., but these are not typical applications of a PC computer, so
there is not much to accelerate. And don't forget about easier alternative
ways, like computing on a GPU present on your video card:
http://tinyurl.com/c5byl
There are several impressive results.
> Yes, FPGAs are costly and can't compare to ASICs...
They can, raw speed is not the only factor that does matter. In my
opinion the order of flexibility provided by FPGAs easily compensates
their lower performance.
> but 50% in an FPGA could mean 400% in an ASIC.
But then you drop the most important feature, which is the ability to
reconfigure the device on the fly.
> If the 32 bit RISC was optimized for some specialized task, then it
> might make sense to have it alongside a high-performance CPU.
No, because in this case you are trying to outperform an out-of-order,
highly parallel processor core able to complete ~6 simple instructions
per cycle and clocked at 2+ GHz. Reasonable soft CPU cores run at
about 200 MHz and complete only one instruction per cycle. It
means that a cheap CPU you can buy anywhere has about 60 times
higher performance in sequential processing. Even if you could provide
the same performance (not to mention about outperforming it, which
is the key idea, anyway), it would mean that you are at least Harry Potter.
:-)
> More interested in prototyping some RISC centric soft-IP designs.
You can do this using existing development boards.
Best regards
Piotr Wyderski
Article: 101816
I have trouble during "Low Level Synthesis" of my code. It gets me
following warings:
WARNING:Xst:1989 - Unit <memoryctr>: instances <Mcompar__n0319>,
<Mcompar__n0290> of unit <LPM_COMPARE_1> are equivalent, second
instance is removed
WARNING:Xst:1710 - FF/Latch <memData_8_17> (without init value) has a
constant value of 0 in block <memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memData_8_16> (without init value) has a constant value of 0 in block
<memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memData_5_17> (without init value) has a constant value of 0 in block
<memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memData_4_17> (without init value) has a constant value of 0 in block
<memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memData_3_17> (without init value) has a constant value of 0 in block
<memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch
<memData_2_17> (without init value) has a constant value of 0 in block
<memoryctr>.
WARNING:Xst:1294 - Latch <Mtridata_sramIO1_0> is equivalent to a wire
in block <memoryctr>.
... ....(from <Mtridata_sramIO1_0> to <Mtridata_sramIO1_15>)
WARNING:Xst:1294 - Latch <Mtridata_sramIO1_15> is equivalent to a wire
in block <memoryctr>.
WARNING:Xst:1710 - FF/Latch <X_31> (without init value) has a constant
value of 0 in block <memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch <X_9>
(without init value) has a constant value of 0 in block <memoryctr>.
... ...(from <X_9> to <X_30>)
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch <X_30>
(without init value) has a constant value of 0 in block <memoryctr>.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch <Y_11>
(without init value) has a constant value of 0 in block <memoryctr>.
... ...(from <Y_11> to <Y_31>)
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch <Y_31>
(without init value) has a constant value of 0 in block <memoryctr>.
mostly are having a constant value of 0 in block <XXX>.
The program is target in a Spartan3 starter board to read and/or write
8 addresses after the incoming address(currentX, currentY) chanages.
Although it isn't follow the coding examples, it setup as a state
machine.
=================
Here is the code:
=================
entity memoryCtr is
Port ( direction : in std_logic_vector(2 downto 0);
currentX : in std_logic_vector(7 downto 0);
currentY : in std_logic_vector(7 downto 0);
reset : in std_logic;
enable : in std_logic;
ready : out std_logic;
action : in std_logic_vector(1 downto 0);
front : out std_logic_vector(15 downto 0);
fright : out std_logic_vector(15 downto 0);
right : out std_logic_vector(15 downto 0);
bright : out std_logic_vector(15 downto 0);
back : out std_logic_vector(15 downto 0);
bleft : out std_logic_vector(15 downto 0);
left : out std_logic_vector(15 downto 0);
fleft : out std_logic_vector(15 downto 0);
clk : in std_logic;
sramIO1 : inout std_logic_vector(15 downto 0);
sramCE1 : out std_logic;
sramUB1 : out std_logic;
sramLB1 : out std_logic;
--sramIO2 : inout std_logic_vector(15 downto 0);
sramAddr : out std_logic_vector(17 downto 0);
--sramCE2 : out std_logic;
--sramUB2 : out std_logic;
--sramLB2 : out std_logic;
sramWE : out std_logic;
sramOE : out std_logic
);
end memoryCtr;
architecture Behavioral of memoryCtr is
constant mapSize: integer := 256; -- 128*128
constant memSize: integer := mapSize/2; -- memSize -> 0 ->
memSize
type memDatas is array (8 downto 0) of std_logic_vector(17 downto 0);
-- the value for memory location
type state_type is (init, setup, read, write, outEnable);
signal state: state_type := init;
begin
memLoop: process(clk)
variable addr :integer;
variable readyEnable: std_logic := '1';
variable X, Y :integer;
variable prevAction : std_logic_vector(1 downto 0) := "00";
variable tempData1, tempData2 : std_logic_vector(15 downto 0) :=
x"0000";
variable FmemData, FRmemData, RmemData, BRmemData,
BmemData, BLmemData, LmemData, FLmemData : std_logic_vector(15
downto 0);
variable memData: memDatas; -- the location for 8
memories
variable dir : integer := 8; -- direction counter
begin
----------------------------------------------------------------------------------------
----------state 1: accept calls and initialize the calls for current
location ----------
----------------------------------------------------------------------------------------
if reset = '1' then
state <= init;
ready <= '0';
dir := 8;
readyEnable := '1';
sramWE <= '0';
sramOE <= '0';
sramAddr <= (others => '1');
sramCE1 <= '1';
sramUB1 <= '1';
sramLB1 <= '1';
sramIO1 <= (others => 'Z');
else
case state is
when init =>
ready <= '0';
if enable = '0' then
readyEnable := '0';
elsif enable = '1' AND dir < 0 then
readyEnable := '0';
elsif enable = '1' AND dir > 0 then
readyEnable := '1';
end if;
dir := 8;
-- calulate and place the current address in the memory bus
if clk = '1' AND readyEnable= '1'
then
if currentX = "1000000" AND currentY = "1000000" then
front <= x"1111";
fleft <= x"1111";
left <= x"1111";
bleft <= x"1111";
back <= x"1111";
bright <= x"1111";
right <= x"1111";
fright <= x"1111";
state <= init;
else
X := CONV_INTEGER(currentX);
Y := CONV_INTEGER(currentY);
addr := CONV_INTEGER(Y)*mapSize+CONV_INTEGER(X);
if action = "01" AND prevAction = "01" then
tempData1 := FmemData;
FmemData := FRmemData;
FRmemData := RmemData;
RmemData := BRmemData;
BRmemData := BLmemData;
BLmemData := LmemData;
LmemData := FLmemData;
FLmemData := tempData1;
dir := -1;
state <= outEnable;
elsif action = "10" AND prevAction = "10" then
tempData1 := FLmemData;
FLmemData := LmemData;
LmemData := BLmemData;
BLmemData := BRmemData;
BRmemData := RmemData;
RmemData := FRmemData;
FRmemData := FmemData;
FmemData := tempData1;
dir := -1;
state <= outEnable;
else
memData(0) := CONV_STD_LOGIC_VECTOR(addr-mapSize, 18);
memData(1) := CONV_STD_LOGIC_VECTOR(addr-mapSize+1, 18);
memData(2) := CONV_STD_LOGIC_VECTOR(addr+1, 18);
memData(3) := CONV_STD_LOGIC_VECTOR(addr+mapSize+1, 18);
memData(4) := CONV_STD_LOGIC_VECTOR(addr+mapSize, 18);
memData(5) := CONV_STD_LOGIC_VECTOR(addr+mapSize-1, 18);
memData(6) := CONV_STD_LOGIC_VECTOR(addr-1, 18);
memData(7) := CONV_STD_LOGIC_VECTOR(addr-mapSize-1, 18);
memData(8) := CONV_STD_LOGIC_VECTOR(addr, 18);
dir := 8;
state <= setup;
end if;
prevAction := action;
end if;
end if;
----------------------------------------------------------------------------------------
----------state 2: setup the buses for read
--------------------------------------------
----------------------------------------------------------------------------------------
when setup => -- for read
ready <= '0';
sramCE1 <= '1';
sramUB1 <= '1';
sramLB1 <= '1';
sramWE <= '0';
sramOE <= '1';
if dir = 8 then
sramAddr <= memData(dir);
elsif CONV_INTEGER(direction)+dir > 7 then
sramAddr <= memData((CONV_INTEGER(direction)+dir-8));
else
sramAddr <= memData((CONV_INTEGER(direction)+dir));
end if;
sramIO1 <= (others => 'Z');
state <= read;
----------------------------------------------------------------------------------------
----------state 3: clear the bus, read the current value,& write if
necessary ----------
----------------------------------------------------------------------------------------
when read => -- reading and break the output before next read or
write
ready <= '0';
sramWE <= '0';
sramOE <= '0';
tempData1 := sramIO1;
sramIO1 <= (others => 'Z');
if tempData1 = "UUUUUUUUUUUUUUUU" OR -- Address have not been
visit,
tempData1 = "0000000000000000" OR -- calculate and place
tempData1 = "XXXXXXXXXXXXXXXX" then -- new data and update it
-- go to write state
state <= write;
elsif action = "11" AND dir = 8
AND X /= memSize AND Y /= memSize then --update the entry
state <= write;
else -- go to output stage
state <= outEnable;
end if;
----------------------------------------------------------------------------------------
----------state 4: write the calcualted value to current entry
-------------------------
----------------------------------------------------------------------------------------
when write => -- updating the value for a entry
ready <= '0';
-- perparing the value
if dir = 8 then -- current location
if tempData1 = "0000000000000000" then -- empty entry
if abs(memSize - X) > abs(memSize - Y) then
tempData1 := CONV_STD_LOGIC_VECTOR(abs(memSize - X), 16)+1;
else
tempData1 := CONV_STD_LOGIC_VECTOR(abs(memSize - Y), 16)+1;
end if;
else -- update entry
tempData1 := tempData1 +1;
end if;
else -- surrounding location
if CONV_INTEGER(direction)+dir > 7 then
X := abs(memSize -
(CONV_INTEGER(memData(CONV_INTEGER(direction)+dir-8)) mod mapSize));
Y := abs(memSize -
(CONV_INTEGER(memData(CONV_INTEGER(direction)+dir-8))/mapSize));
else
X := abs(memSize -
(CONV_INTEGER(memData(CONV_INTEGER(direction)+dir)) mod mapSize));
Y := abs(memSize -
(CONV_INTEGER(memData(CONV_INTEGER(direction)+dir))/mapSize));
end if;
if X > Y then
tempData1 := CONV_STD_LOGIC_VECTOR(X, 16);
else
tempData1 := CONV_STD_LOGIC_VECTOR(Y, 16);
end if;
end if;
-- follow signal did not change since setup
sramCE1 <= '1';
sramUB1 <= '1';
sramLB1 <= '1';
sramWE <= '1';
sramOE <= '0';
sramIO1 <= tempData1;
state <= outEnable;
----------------------------------------------------------------------------------------
----------state 5: check if all done, yes then output all the values
-------------------
---------- else back to setup stage
-------------------
----------------------------------------------------------------------------------------
when outEnable => -- if all done then output state
sramWE <= '0'; -- just a safe to clear the bus again
sramOE <= '0';
sramIO1 <= (others => 'Z');
if dir = 0 then
FmemData := tempData1;
end if;
if dir = 1 then
FRmemData := tempData1;
end if;
if dir = 2 then
RmemData := tempData1;
end if;
if dir = 3 then
BRmemData := tempData1;
end if;
if dir = 4 then
BmemData := tempData1;
end if;
if dir = 5 then
BLmemData := tempData1;
end if;
if dir = 6 then
LmemData := tempData1;
end if;
if dir = 7 then
FLmemData := tempData1;
end if;
dir := dir - 1;
if dir >= 0 then -- back to setup stage
state <= setup;
else -- all done, send the output the cooresponding
port
ready <= '1';
front <= FmemData;
fright <= FRmemData;
right <= RmemData;
bright <= BRmemData;
back <= BmemData;
bleft <= BLmemData;
left <= LmemData;
fleft <= FLmemData;
state <= init;
end if;
when others =>
state <= init;
end case;
end if;
end process;
end Behavioral;
Any help on this would be greatly appreciated.
Thanks very much in advance.
YiQi
Article: 101817Hi, all, sorry if the question appears stupid, I just want to get it start. also sorry about my poor english(it isn't my first language), hope you can understand what I mean. My orignal design is done in VHDL. I have generate the edif from Xilinx. After reading most of the introduction, I think JHDL will be able to help me reading the EDIF file. What I try to do is read the EDIF file and conver it into my own structure (a chromosome of the circuit), follow by genetic algorithm, to produce a new function with the circuit. In my understanding, edif file captures the gates, FF, and wires only, there is not architecture dependent. Let me know if I am wrong. Therefore, my questions are following: 1. Why do we need to specify the architecture(target) during VHDL -> JHDL using EDIFParser? 2. Because JHDL doesn't support asynchoronous loop. Is there any software might do a better job than JHDL on simulating EDIF file as a black box with VHDL? It will be even better if it can be done by scrpit or command line (so that could be control by my java GA program) Any help on this would be greatly appreciated. Thanks very much in advance. YiQi HuangArticle: 101818
On 7 May 2006 03:24:49 -0700, "Jep" <Laurent.George@gmail.com> wrote: >I have a little problem with flashing a led. > >I want flash a led for indicating the status of my program. > >I do the following: > >LED1 <= '1', '0' after 200 us; > >But it burn all the time. > >Do you have a solution? ( wthout counters) If it burns, it has too much forwar current, try instead: LED1<= '1' through 200 ohms, '0' after 200 us ;-) ZaraArticle: 101819
The following warning is issued: "WARNING:Xst:1294 - Latch <latch_name> is equivalent to a wire in block <block_name>." Solution 1: This problem is fixed in the latest 5.1i Service Pack, available at: http://support.xilinx.com/support/techsup/sw_updates The first service pack containing the fix is 5.1i Service Pack 1. Above message from Xilinx's web site, But I am using 7.1i already, it isn't that my errors should be fixed?Article: 101820
"Tony Burch" <tony@burched.com.au> wrote in message news:445d9a81$0$25129$afc38c87@news.optusnet.com.au... > Hi, just a note that the FPGA boards bonus-sets offer is closing tonight > around midnight. I was going to leave that till the evening to take a look but I remembered you're in Australia and thus about 10 hours ahead of the UK. Therefore I have about half an hour to do any shopping!Article: 101821
Hi,
Based on suggestions from this group, when switching libraries from
USE ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
to
USE ieee.std_logic_1164.all;
use ieee.numeric_std.all;
this morning I really found a big new issue dealing with
'std_logic_vector' and 'unsigned'.
Here is the definition of 'unsigned' from ieee.numeric_std.vhd:
type UNSIGNED is array (NATURAL range <>) of STD_LOGIC;
Here is the definition of 'std_logic_vector' from ieee.stdlogic.vhd:
TYPE std_logic_vector IS ARRAY ( NATURAL RANGE <>) OF std_logic;
Actually one cannot see any big differences between 'unsigned' and
'std_logic_vector'.
But the following code shows big differences between the two's
behaviors within a generate loop:
signal A : unsigned(1 downto 0);
...
Generate_A : for I in 0 to 3 generate
ModuleX : port map (
...
A => A(I), <-- error due to A's range between 1-0 while I = 2
...
);
end generate;
signal A : std_logic_vector(1 downto 0);
...
Generate_A : for I in 0 to 3 generate
ModuleX : port map (
...
A => A(I), <-- no error, because integer I is between 3-0
-- and A's range is 3-0 due to its definition
of 2 bits
...
);
end generate;
Why?
Thank you.
Weng
Article: 101822David M. Palmer (dmpalmer@email.com) wrote: : In article <1146955848.154397.42440@i40g2000cwc.googlegroups.com>, : BoroToro <beiermann@gmail.com> wrote: : > I just received my Spartan 3e starter kit and had to share my : > frustration... : > <s nip > : Does anyone know if doing PWM on the VGA output pins would cause Bad : Things to happen to a typical monitor? I tried it with the Spartan 3 kit from Xilinx/Digilent a while back and had some success with PWM - if you count success to mean working on 1 of 4 CRTs tested... And working being used in a foregiving sense :-) cdsArticle: 101823
Weng Tianxiang wrote: > Actually one cannot see any big differences between 'unsigned' and > 'std_logic_vector'. The package contains much more than that type declaration. Have a look at the functions that cover unsigned. http://www.csee.umbc.edu/help/VHDL/packages/numeric_std.vhd -- Mike TreselerArticle: 101824
YiQi wrote:
> The following warning is issued:
> Above message from Xilinx's web site, But I am using 7.1i already, it
> isn't that my errors should be fixed?
Try fitting your code into a template like this
begin
if reset = '1' then
init_regs;
elsif rising_edge(clock) then
update_regs;
end if;
update_ports;
end process sync_template;
-- Mike Treseler
It is not in the stars
to hold our destiny but in ourselves.
-William Shakespeare
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