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
"Dave Vanden Bout" <devb@xess.com> wrote in message news:3FA18F22.83975E8C@xess.com... > WebPACK supports Verilog. You will go through the same operations, dialogs, > windows, etc whether you use Verilog or VHDL so the tutorial should still be > applicable. The only added effort is to develop your own Verilog code to > replace the VHDL already given for the LED decoder and the counter. Thanks. There was once a discussion that seemed to say that verilog is used for ASICs and VHDL for FPGA's. I wanted to be sure. -- glenArticle: 62501
John Blaine <john.blaine@xilinx.com> wrote in message news:<3F9FA363.7930A312@xilinx.com>... > Praveen, > > It is difficult to estimate how much impact this will have on the power > estimate. > So let me take you through a few points: > > Using a post PAR estimate will allow XPower to have an accurate estimate > of > capacitance load on the internal routes so no problem here. If you are > using post MAP > where no SDF is generated then this is a large source of inaccuracy and > is not > recommended. > > Now lets look at the timing simulations tend to result in glitches. This > switching translates > into higher activity rates in XPower-> higher power. > > I would expect these to be fairly low load signals. Also if you have a > fully synchronous > design this effect will be limited. > > Your clocks will be set correctly (high power consuming nets). > If you have met timing (verifed through timing analyser) then other > heavy loaded signals like > clock enables, should be set correctly. > > So in summary, if your design is post PAR, fully synchronous and has met > timing, you should > be OK an get an accurate power estimate. > > John > > praveen wrote: > > > hi all, > > > > i am calculating the power consumption using xilinx xpower. For > > generating the VCD file i am not loading the SDF(Standard Delay > > Format) during VSIM. Will it affect the power calculation. > > > > thanks in advance. > > -- hi john, as u said our design is fully synchronous and our entire design is working on only one clock edge, and more over ther are no latches inferred in our design , so chances of glitches are minimal. so not loading the SDF file will not make much differnce in th power estimate i guess. one more thing i wanted to ask u regarding the power consumption, we r using XILINX virtex 2p (XC2VP50 -6 FF1517) . what is the power that is tolerable without providing heat sinks. praveenArticle: 62502
>By the way, the XC95108 has 108 cells , what are cells ? so the >sc95108 can store 108 flip-flops ? You really should read the data sheet. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 62503
Hi,
I am just starting out with respect to utilising FPGAs within my designs. Up
to this point in time I've mostly been involved with microcontroller based
designs, but I'm seeing where FPGAs can help solve various types of tasks I
find myself in and hence wanting to learn how to use them properly.
I've brought a small development board and have gradually implemented
various designs for making various beeps and sirens on a speaker, and
decoders such as a binary to 7segment decoder etc etc. I term them "simple"
designs since they are designs that can be "completely wrong" but at the
same time still "work" (i.e. yes it does what I set out to do, but the
design techniques might not be the best, or it wouldn't work if I had a bit
a little more clock slew etc etc...).
I am at the stage where I think I am almost confident enough to design a
FPGA into a hobby project of my own with enough confidence that I'll be
able to develop the right VHDL source to make it "tick"...
To this end I've started attempting to simulate/develop a 68HC11 to Wishbone
interface (the idea being to graft an FPGA onto the databus of an existing
HC11 produt) and I'd like some advice on what I've got so far. Not knowing
much about data busses typically utilised within FPGA designs etc Wishbone
looked like a good idea, especially when sites such as www.opencores.org
appear to support it for their freely available cores.
My VHDL source for a wishbone master which has an HC11 data bus interface on
the other end is shown below. It's a slightly "confused" master, in that
it's not as seperted out as the Wishbone specification details, i.e. it's
got elements of an InterCon and SysCon module thrown in as well... Sorry
about the poor coding standard (the Wishbone/HC11 bus signals are named
using different conventions etc), I just thought I'd "throw it out there"
rather than worrying about tiding it up first...
entity hc11_wb_master is
port (
-- Wishbone bus interface
WB_CLK_O : out std_logic; -- Clock
WB_RST_O : out std_logic; -- Reset
WB_ADR_O : out std_logic_vector(1 downto 0);
WB_DAT_I : in std_logic_vector(7 downto 0);
WB_DAT_O : out std_logic_vector(7 downto 0);
WB_WE_O : out std_logic; -- Write enable
WB_STB_O : out std_logic; -- Strobe
-- HC11 bus interface
e_clk : in std_logic;
reset : in std_logic;
cs : in std_logic; -- chip select for FPGA (HC11's CS2)
rw : in std_logic; -- read/write* strobe
addr : in std_logic_vector(10 downto 0);
data : inout std_logic_vector(7 downto 0);
);
end hc11_wb_master;
architecture Behavioral of hc11_wb_master is
signal write_cycle : std_logic;
begin
WB_CLK_O <= not e_clk; // HC11 clocks on the opposite edge to Wishbone
-- Asserted if the HC11 bus cycle is a memory write
write_cycle = not(rw);
process (e_clk)
begin
if (falling_edge(e_clk)) then
WB_RST_O <= not reset; -- HC11 is active low reset
data <= "ZZZZZZZZ";
if (reset = '0') then
-- Reset condition - hold wishbone bus inactive
WB_STB_O <= '0';
else
-- Translate the various control signals from HC11 to wishbone
WB_WE_O <= write_cycle;
WB_ADR_O <= addr(1 downto 0);
WB_STB_O <= cs;
-- Transfer data in the correct direction...
if (cs = '1') then
if (write_cycle = '1') then
WB_DAT_O <= data;
else
data <= WB_DAT_I;
end if;
end if;
end if;
end if;
end process;
end Behavioral;
Now there are various things that with my present dismal knowledge I am not
sure about. It seems it simulates ok..., I have a testbench where I've
attached it to a UART module from www.opencores.org and I can see in the
resultant simulation a write to the UART and the resultant activity on the
UART's TX pin etc etc...
However I have questions...
For example the line
WB_CLK_O <= not e_clk;
I utilised to invert the polarity of the clock between the two busses. My
idea is to clock the wishbone bus via the HC11's E-clock to keep the
wishbone bus transactions synchronous to the HC11's bus operations (seems
logical to me). The problem is the HC11 reads/writes on the falling edge,
while the wishbone interface does it on the rising edge... But isn't this
inversion I've done inheriently evil or "bad design"?
I have read discussions about the problems of gated clocks causing problems
with respect to routing and propagation delays. Isn't this the same sort of
issue? Everything hanging off the wishbone interface is going to be clocked
via WB_CLK_O which although not "gated", it's going through a minimal
amount of logic from the actual clock signal entering the FPGA. Perhaps
it's not a concern? Perhaps the systhensis tools are smart enough to mean I
don't have to worry about it..
I am also interested with respect to how I've attempted to implement the
tri-stateable interface for the 8bit data port to the HC11's bus. Am I
heading in the right direction in this respect?
Another thing thats going to show how completely clueless I am... is with
respect to setup/hold timing. The logic I've implemented above (to my
knoweldge at least) will latch the wishbone data onto the HC11's databus on
the falling edge of the eclock (assuming the HC11 initiates a read cycle of
course).. but this is also the same time that I'm latching the incomming
address signals and obviously it's not going to have time to propogate
through the logic, cause the wishbone slave to dump the correct data onto
the databus and be latched... What am I doing wrong here, and in what way
would I go about starting to make changes to correct this... I assume the
only reason it's simulated fine so far is that I've done my simulation
before the synthesis stage, and hence there's no "timing/routing" related
info in the simulation. Am I correct in my understanding here?
Now knowing me the code I placed above is completely wrong for this and many
other reasons.. but that is why I would appreciate any advice you could
provide me. I'm doing this exercise purely as a learning exercise so the
more avanues I find for further learning the better :-)
One thing this project has highlighted is the need for me to learn more
about writing better testbenches... I totally agree with the comments I've
seen in this newgroup about newbies starting out with a simulator and no
physical hardware. I sure wish I had started out that way :-)
My aim with this project is to eventually get an HC11 talking to some
perhperials implemented within an FPGA that are wishbone slaves. The
perpherials are rather basic themselfs, mainly boiling down to a couple of
high speed counters at this stage.
Thanks,
Christopher Fairbairn.
PS: Can anyone suggest a good book on Simulation, in particular with
relation to VHDL? I've identified this as an area where I'm particular
weak, and as an area where improvements would make progress a bit smoother.
For example how do you go about reading in stimulius from a file so I don't
have to hardcode in bus transactions in my testbench, and can instead
simply read them in from a file containing "read 0x8000, write 0x7000" or
the equivalent...
Article: 62504Brad Eckert <brad@tinyboot.com> wrote: : No problem in the US. China is another story, where IP rip-off is : business as usual. Cultural change doesn't happen overnight. If I look at US patents, espexially those Internet relates, there's no difference... -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 62505
Erik Widding <widding@birger.com> wrote in message news:Racob.28628$294.15708@nwrdny03.gnilink.net... > We have been using a rechargeable lithium battery ($1.25 / 4mAh) > that is soldered directly to the PCB. Add a low leakage diode and > a current limiting resistor for a recharger circuit and you do not > need to worry about replacement. The only requirement is that the > board be powered up for a few hours every couple of years. The > only issue that we have with this is that the batteries can't tolerate > the oven, and must be hand soldered. > Erik Widding. Erik, are you not in danger of over charging the battery? Don't phone batterys degrade fairly quickly if they're constantly trickle charged rather than being fully discharged then re-charged? Are the characteristics of your batterys different? Have you done any long term tests with this set up? Are your boards only likely to be powered up every now and then to stop this happening? I'm not trying to pick holes, just interested. NialArticle: 62506
"Tim" <tim@rockylogic.com.nooospam.com> wrote in message = news:bnnrul$de5$1$8302bc10@news.demon.co.uk... > philip wrote: > > Try one of the Logic Analysers available from Acute. > > > > http://www.acute.com.tw/indexeng.htm > > I don't know what is inside these products, but for lovers > of recursion it is almost certainly one or more FPGAs. > > Ditto the somewhat less expensive stuff at www.rockylogic.com, > to which I contributed the design errors ;-) Sorry to be boring and ask the same again(well six months later) but when is the api gong to be available ? You guys keep saying soon.Article: 62507
Hello, can you tell me if there are application notes available about Address Mapping in 4K RAM Blocks in Altera Cyclone Devices? Thank you. Kind regards Andres V. G&D System DevelopmentArticle: 62508
henk@mediatronix.com (Henk van Kampen) wrote in message news:<23ecd97d.0310280507.229567b@posting.google.com>... > > this cant be used with Cable IV, because the API and documentation > > about Cable IV are kept as secret. > > I have successfully used a Cable IV assuming it is a Cable III. The > only problem is that iMPACT leaves the cable and your port in an > undefined state, so you have to reset the ECP mode and reset the cable > (reset printer). Of course you will not benefit from the ECP speed > possible with the Cable IV. > > Henk van Kampen > www.mediatronix.com do you want to say that Cable IV is Cable III backward compatible in non-ECP mode? if it so then it very good information anttiArticle: 62509
You can find it at: http://www.altera.com/literature/hb/cyc/cyc_c51007.pdf More information on Cyclone features can be found at: http://www.altera.com/literature/lit-cyc.jsp - Subroto Datta Altera Corp. "Vazquez" <andres.vazquez@gmx.de> wrote in message news:eee19a7a.0310310445.30c66b7f@posting.google.com... > Hello, > > can you tell me if there are application notes available about > Address Mapping in 4K RAM Blocks in Altera Cyclone Devices? > > Thank you. > > Kind regards > > Andres V. > G&D System DevelopmentArticle: 62510
Hi, I'm new to this newsgroup, and also a relative FPGA newbie (though have lots of hardware and software experince). If I should need the FAQ, please kindly point me in the right direction. I would like to implement a minimal RS232 interface on my Cyclone device. I only require TxD and RxD signals (I've got an RS232 level- shifter IC on board). I only require a bare-bones implementation as I need to communicate merely sufficient data to configure up to 16 8-bit registers on my Cyclone chip. Flow-control / buffer overruns should not be an issue. It would be nice to have a terminal-like behaviour from the Cyclone (and enter commands like "R13:240" to set register 13 to value 240). A terse (and technically simpler) command structure such as "0af8[enter]" meaning: "set register 0x0a to 0xf8" would be perfectly adequate for the time being. What is the best way to implement this function? Is there code I can download from the website? I'm using the Quartus II software, and using a mixture of Graphical (Block) Design Files and AHDL. My present application does not require or use any Nios core. I see downloadable UARTs on the site, but they are far more fully- functioned than I need, and apparently require licensing, which seems far too complicated and involved for a one-off project. Thanks for any suggestion, Andrew SPAMTRAP: Please be sure to de-munge address if replying by email.Article: 62511
MiniUART is available from opencores. I've modified it to make even "lighter" but it should exactly satisfy your needs.Article: 62512
Nial, You will not damage or over-charge the battery if you follow the manufacturer's recommendations. It is amazing how few engineers have even looked at, read, and used the data sheets for a battery. It is a component just like any other: study it, learn its characteristics, and then design it in. You can blow out any component you want, caps, resistors, transistors, and batteries, too if you do not read the datasheet. Go look thru the design guides for the battery chemistry you want to use: you will be glad you did. Austin Nial Stewart wrote: > Erik Widding <widding@birger.com> wrote in message > news:Racob.28628$294.15708@nwrdny03.gnilink.net... > > We have been using a rechargeable lithium battery ($1.25 / 4mAh) > > that is soldered directly to the PCB. Add a low leakage diode and > > a current limiting resistor for a recharger circuit and you do not > > need to worry about replacement. The only requirement is that the > > board be powered up for a few hours every couple of years. The > > only issue that we have with this is that the batteries can't tolerate > > the oven, and must be hand soldered. > > Erik Widding. > > Erik, are you not in danger of over charging the battery? > > Don't phone batterys degrade fairly quickly if they're > constantly trickle charged rather than being fully > discharged then re-charged? Are the characteristics > of your batterys different? > Have you done any long term tests with this set up? > > Are your boards only likely to be powered up every now and > then to stop this happening? > > I'm not trying to pick holes, just interested. > > NialArticle: 62513
Hi NG, are essential hazards avoided in CPLD-designs? If for example I were to design a counter with a subsequent comparator in a CPLD, would I be sure that I got no glitches in the output from my comparator? Or would I have to filter the output before I used it in other part of the CPLD? Best regards PrebenArticle: 62514
Preben Mikael Bohn wrote: > Hi NG, are essential hazards avoided in CPLD-designs? They can be. > If for example I were to design a counter with a subsequent comparator > in a CPLD, would I be sure that I got no glitches in the output from my > comparator? If you use synchronous design and do static timing analysis, your outputs won't glitch. -- Mike TreselerArticle: 62515
If you implement a binary counter and compare its output against another binary value, there is no way on this earth to avoid combinatorial glitches, no matter what technology or circuit design you use. The classical solution to this problem is to Gray-code the counter, so that only one bit changes at a time. Of course, you can also re-synchronize the comparator output and thus suppress all combinatorial glitches... Peter Alfke ======================================== Preben Mikael Bohn wrote: > > Hi NG, are essential hazards avoided in CPLD-designs? > > If for example I were to design a counter with a subsequent comparator > in a CPLD, would I be sure that I got no glitches in the output from my > comparator? Or would I have to filter the output before I used it in > other part of the CPLD? > > Best regards PrebenArticle: 62516
"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3FA28A84.AAA1FE7A@xilinx.com... > Nial, > > You will not damage or over-charge the battery if you follow the > manufacturer's recommendations. > > It is amazing how few engineers have even looked at, read, and used the data > sheets for a battery. > > It is a component just like any other: study it, learn its characteristics, > and then design it in. I don't know the details, but Li ion is very different from NiCd. Some years ago all we had was NiCd, charged at 0.1C (take the milliamp-hour rating, divide by 10, and charge at that many milliamps) for 14 hours. That was all anyone needed to know. Now there are so many different battery chemistries, each with its own charging characteristics and discharge characteristics. -- glenArticle: 62517
I am looking for Microblaze ports in Xess XSV800 (www.xess.com) board platform and a ucLinux (www.uclinux.org) tutorial/experience in that board. Thanks in advance.Article: 62518
I have an XC2S300E-pq08 which the data sheet says has 146 user I/O max. However, the PAR says: Number of bonded IOBs: 144 out of 142 101% There are still quite a few I/O pins left on my dev board. I'm puzzled that it seems I can use any I/O pins but less than all of them at the same time. Is this the case or am I missing something fundamental? Thanks in advance, K. Command Line : map -p XC2S300E-pq208-6 -cm area -k 4 -c 100 -tx off Target Device : x2s300e Target Package : pq208 Target Speed : -6 Mapper Version : spartan2e -- $Revision: 1.58 $ Mapped Date : Fri Oct 31 01:02:35 2003Article: 62519
>It would be nice to have a terminal-like behaviour from the Cyclone >(and enter commands like "R13:240" to set register 13 to value 240). A >terse (and technically simpler) command structure such as "0af8[enter]" >meaning: "set register 0x0a to 0xf8" would be perfectly adequate for >the time being. That's not really terse. You have to do the ascii/hex to binary conversions. Of course, that's just software. If you use 8 bits with parity, you really have 9 bits. You could use the 9th bit as a command flag. You could probably do it all in hardware if that was interesting. Might be handy in the real early bringup stages. If you have fewer than 256 registers you could use a bit (in command mode) as a read/write flag and get it to send back register contents. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 62520
Hi!
> To this end I've started attempting to simulate/develop a 68HC11 to
Wishbone
> interface (the idea being to graft an FPGA onto the databus of an existing
> HC11 produt) and I'd like some advice on what I've got so far. Not knowing
> much about data busses typically utilised within FPGA designs etc Wishbone
> looked like a good idea, especially when sites such as www.opencores.org
> appear to support it for their freely available cores.
I've done a similar project before: I have an async master to WB interface.
It's (as far as I can tell) working but it's not an easy task to do.
> My VHDL source for a wishbone master which has an HC11 data bus interface
on
> the other end is shown below. It's a slightly "confused" master, in that
> it's not as seperted out as the Wishbone specification details, i.e. it's
> got elements of an InterCon and SysCon module thrown in as well... Sorry
> about the poor coding standard (the Wishbone/HC11 bus signals are named
> using different conventions etc), I just thought I'd "throw it out there"
> rather than worrying about tiding it up first...
>
> entity hc11_wb_master is
> port (
> -- Wishbone bus interface
> WB_CLK_O : out std_logic; -- Clock
> WB_RST_O : out std_logic; -- Reset
> WB_ADR_O : out std_logic_vector(1 downto 0);
> WB_DAT_I : in std_logic_vector(7 downto 0);
> WB_DAT_O : out std_logic_vector(7 downto 0);
> WB_WE_O : out std_logic; -- Write enable
> WB_STB_O : out std_logic; -- Strobe
> -- HC11 bus interface
> e_clk : in std_logic;
> reset : in std_logic;
> cs : in std_logic; -- chip select for FPGA (HC11's CS2)
> rw : in std_logic; -- read/write* strobe
> addr : in std_logic_vector(10 downto 0);
> data : inout std_logic_vector(7 downto 0);
> );
> end hc11_wb_master;
>
> architecture Behavioral of hc11_wb_master is
> signal write_cycle : std_logic;
> begin
> WB_CLK_O <= not e_clk; // HC11 clocks on the opposite edge to
Wishbone
>
> -- Asserted if the HC11 bus cycle is a memory write
> write_cycle = not(rw);
>
> process (e_clk)
> begin
> if (falling_edge(e_clk)) then
> WB_RST_O <= not reset; -- HC11 is active low reset
>
> data <= "ZZZZZZZZ";
>
> if (reset = '0') then
> -- Reset condition - hold wishbone bus
inactive
> WB_STB_O <= '0';
> else
> -- Translate the various control signals
from HC11 to wishbone
> WB_WE_O <= write_cycle;
> WB_ADR_O <= addr(1 downto 0);
> WB_STB_O <= cs;
>
> -- Transfer data in the correct
direction...
> if (cs = '1') then
> if (write_cycle = '1') then
> WB_DAT_O <= data;
> else
> data <= WB_DAT_I;
> end if;
> end if;
> end if;
> end if;
> end process;
> end Behavioral;
There are some problems with this design:
- You don't handle error and retry requests from the WB side and don't
generate WB_CYC_O.
- There's no wait-state generation. You don't detect any wait-state requests
from the WB side and don't generate wait-states for your async master
(HC11). That can cause problems if you communicate with slow devices (for
example with a FIFO which, when full, generated waits)
- More importantly, your logic is all wrong. The WB bus is syncronous and
have this feature: a cycle starts by the master asserts WB_CYC_O (which you
don't generate to begin with) and ends when the target asserts WB_ACK_I (or
WB_ERR_I or WB_RTY_I). After that, at the next clock, if WB_CYC_O remains
active, it starts a new cycle. So your logic can generate multiple writes or
reads to/from the same location depending on the timing. That can cause
serious problems with transmit or receive FIFOs even in your case of the
serial controller. (If not, than that's a bug in the serial controller...)
Even more problematic is that this 'feature' combined with the lack of
proper wait-state handling can cause invalid data to be written to any
location and invalid data to be read from any location that are not
zero-wait-state.
I'm sorry, I've been down that road too, so I know :-(...
> Now there are various things that with my present dismal knowledge I am
not
> sure about. It seems it simulates ok..., I have a testbench where I've
> attached it to a UART module from www.opencores.org and I can see in the
> resultant simulation a write to the UART and the resultant activity on the
> UART's TX pin etc etc...
>
> However I have questions...
>
> For example the line
>
> WB_CLK_O <= not e_clk;
>
> I utilised to invert the polarity of the clock between the two busses. My
> idea is to clock the wishbone bus via the HC11's E-clock to keep the
> wishbone bus transactions synchronous to the HC11's bus operations (seems
> logical to me). The problem is the HC11 reads/writes on the falling edge,
> while the wishbone interface does it on the rising edge... But isn't this
> inversion I've done inheriently evil or "bad design"?
>
> I have read discussions about the problems of gated clocks causing
problems
> with respect to routing and propagation delays. Isn't this the same sort
of
> issue? Everything hanging off the wishbone interface is going to be
clocked
> via WB_CLK_O which although not "gated", it's going through a minimal
> amount of logic from the actual clock signal entering the FPGA. Perhaps
> it's not a concern? Perhaps the systhensis tools are smart enough to mean
I
> don't have to worry about it..
I don't think it is an issue.
> I am also interested with respect to how I've attempted to implement the
> tri-stateable interface for the 8bit data port to the HC11's bus. Am I
> heading in the right direction in this respect?
Tri-state seems to be OK.
> Another thing thats going to show how completely clueless I am... is with
> respect to setup/hold timing. The logic I've implemented above (to my
> knoweldge at least) will latch the wishbone data onto the HC11's databus
on
> the falling edge of the eclock (assuming the HC11 initiates a read cycle
of
> course).. but this is also the same time that I'm latching the incomming
> address signals and obviously it's not going to have time to propogate
> through the logic, cause the wishbone slave to dump the correct data onto
> the databus and be latched... What am I doing wrong here, and in what way
> would I go about starting to make changes to correct this... I assume the
> only reason it's simulated fine so far is that I've done my simulation
> before the synthesis stage, and hence there's no "timing/routing" related
> info in the simulation. Am I correct in my understanding here?
Setup-hold times are device (and place-and-route) specific, so I can't
answer that without knowing more about your target architecture. The FPGA
and uP datasheet should answer most of your questions. In general FPGAs are
much faster than an HC11 so you might have setup problems on the HC11 side
but others should work fine.
I'll paste my circuit here for reference. Note, that it does not use the
CPUs clock to sync up the WB part, so it can run on much higher clock speeds
(in my case 70MHz). That can help meet the timing (with proper wait-state
handling of course) but can cause all kinds of meta-stability issues, I'm
not sure I've addressed properly either. Please note that I'm not a
professional either, I'm not claiming my design to be nice or flowless. It
at least worked in a real HW... Any comment are welcome.
Andras Tantos
================================================================
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity wb_async_master is
generic (
dat_width: positive := 16;
adr_width: positive := 20;
ab_rd_delay: positive := 1
);
port (
wb_clk_i: in std_logic;
wb_rst_i: in std_logic := '0';
-- interface to wb slave devices
wb_adr_o: out std_logic_vector (adr_width-1 downto 0);
wb_sel_o: out std_logic_vector ((dat_width/8)-1 downto 0);
wb_dat_i: in std_logic_vector (dat_width-1 downto 0);
wb_dat_o: out std_logic_vector (dat_width-1 downto 0);
wb_cyc_o: out std_logic;
wb_ack_i: in std_logic;
wb_err_i: in std_logic := '-';
wb_rty_i: in std_logic := '-';
wb_we_o: out std_logic;
wb_stb_o: out std_logic;
-- interface to the asyncronous master device
ab_dat: inout std_logic_vector (dat_width-1 downto 0) := (others =>
'Z');
ab_adr: in std_logic_vector (adr_width-1 downto 0) := (others =>
'U');
ab_rd_n: in std_logic := '1';
ab_wr_n: in std_logic := '1';
ab_ce_n: in std_logic := '1';
ab_byteen_n: in std_logic_vector ((dat_width/8)-1 downto 0);
ab_wait_n: out std_logic; -- wait-state request 'open-drain' output
ab_waiths: out std_logic -- handshake-type totem-pole output
);
end wb_async_master;
architecture xilinx of wb_async_master is
constant ab_wr_delay: positive := 2;
-- delay lines for rd/wr edge detection
signal rd_delay_rst: std_logic;
signal rd_delay: std_logic_vector(ab_rd_delay downto 0);
signal wr_delay: std_logic_vector(ab_wr_delay downto 0);
-- one-cycle long pulses upon rd/wr edges
signal ab_wr_pulse: std_logic;
signal ab_rd_pulse: std_logic;
-- one-cycle long pulse to latch address for writes
signal ab_wr_latch_pulse: std_logic;
-- WB data input register
signal wb_dat_reg: std_logic_vector (dat_width-1 downto 0);
-- internal copies of WB signals for feedback
signal wb_cyc_l: std_logic;
signal wb_we_l: std_logic;
-- Comb. logic for active cycles
signal ab_rd: std_logic;
signal ab_wr: std_logic;
signal ab_active: std_logic;
-- internal copies of wait signals for feedback
signal ab_wait_n_rst: std_logic;
signal ab_wait_n_l: std_logic;
signal ab_waiths_l: std_logic;
signal ab_wait_n_l_delayed: std_logic;
signal ab_waiths_l_delayed: std_logic;
-- active when WB slave terminates the cycle (for any reason)
signal wb_ack: std_logic;
-- signals a scheduled or commencing posted write
signal write_in_progress: std_logic;
begin
ab_rd <= (not ab_ce_n) and (not ab_rd_n) and ab_wr_n;
ab_wr <= (not ab_ce_n) and (not ab_wr_n) and ab_rd_n;
ab_active <= not ab_ce_n;
wb_ack <= wb_cyc_l and (wb_ack_i or wb_err_i or wb_rty_i);
write_in_progress_gen: process
begin
if (wb_rst_i = '1') then
write_in_progress <= '0';
end if;
wait until wb_clk_i'EVENT and wb_clk_i = '1';
if ab_wr = '0' and wr_delay(wr_delay'HIGH) = '1' then
write_in_progress <= '1';
end if;
if wb_ack = '1' then
write_in_progress <= '0';
end if;
end process;
-- Registers addr/data lines.
reg_bus_lines: process
begin
if (wb_rst_i = '1') then
wb_adr_o <= (others => '-');
wb_sel_o <= (others => '-');
wb_dat_o <= (others => '-');
wb_dat_reg <= (others => '0');
end if;
wait until wb_clk_i'EVENT and wb_clk_i = '1';
-- Store and sycnronize data and address lines if no (posted) write
-- is in progress and there is an active asyncronous bus cycle.
-- We store addresses for reads at the same time we sample the data
so setup and hold
-- times are the same.
if (ab_wr = '1' or ab_rd_pulse = '1') and (write_in_progress = '0'
or wb_ack = '1') then
wb_adr_o <= ab_adr;
for i in wb_sel_o'RANGE loop
wb_sel_o(i) <= not ab_byteen_n(i);
end loop;
end if;
if (ab_wr = '1') and (write_in_progress = '0' or wb_ack = '1') then
wb_dat_o <= ab_dat;
end if;
-- en-register data input at the end of a read cycle
if wb_ack = '1' then
if wb_we_l = '0' then
-- read cycle completed, store the result
wb_dat_reg <= wb_dat_i;
end if;
end if;
end process;
-- Registers asycn bus control lines for sync edge detection.
async_bus_wr_ctrl : process(wb_rst_i,wb_clk_i)
begin
if (wb_rst_i = '1') then
wr_delay <= (others => '0');
elsif wb_clk_i'EVENT and wb_clk_i = '0' then
-- delayed signals will be used in edge-detection
for i in wr_delay'HIGH downto 1 loop
wr_delay(i) <= wr_delay(i-1);-- and ab_rd;
end loop;
wr_delay(0) <= ab_wr;
end if;
end process;
rd_delay_rst <= wb_rst_i or not ab_rd;
async_bus_rd_ctrl : process(rd_delay_rst,wb_clk_i)
begin
if (rd_delay_rst = '1') then
rd_delay <= (others => '0');
-- Post-layout simulation shows glitches on the output that violates
setup times.
-- Clock on the other edge to solve this issue
elsif wb_clk_i'EVENT and wb_clk_i = '0' then
-- a sync-reset shift-register to delay read signal
for i in rd_delay'HIGH downto 1 loop
rd_delay(i) <= rd_delay(i-1) and ab_rd;
end loop;
if (wb_cyc_l = '1') then
rd_delay(0) <= rd_delay(0);
else
rd_delay(0) <= ab_rd and not write_in_progress;
end if;
end if;
end process;
-- will be one for one cycle at the proper end of the async cycle
ab_wr_pulse <= wr_delay(wr_delay'HIGH) and not
wr_delay(wr_delay'HIGH-1);
ab_wr_latch_pulse <= not wr_delay(wr_delay'HIGH) and
wr_delay(wr_delay'HIGH-1);
ab_rd_pulse <= not rd_delay(rd_delay'HIGH) and
rd_delay(rd_delay'HIGH-1);
-- Generates WishBone control signals
wb_ctrl_gen: process
begin
if (wb_rst_i = '1') then
wb_stb_o <= '0';
wb_cyc_l <= '0';
wb_we_l <= '0';
end if;
wait until wb_clk_i'EVENT and wb_clk_i = '1';
if wb_ack = '1' and ab_wr_pulse = '0' and ab_rd_pulse = '0' then
wb_stb_o <= '0';
wb_cyc_l <= '0';
wb_we_l <= '0';
end if;
if ab_wr_pulse = '1' or ab_rd_pulse = '1' then
wb_stb_o <= '1';
wb_cyc_l <= '1';
wb_we_l <= ab_wr_pulse;
end if;
end process;
-- Generate asyncronous wait signal
ab_wait_n_rst <= wb_rst_i or not ab_active;
a_wait_n_gen: process(ab_wait_n_rst, wb_clk_i)
begin
if (ab_wait_n_rst = '1') then
ab_wait_n_l <= '1';
elsif wb_clk_i'EVENT and wb_clk_i = '1' then
-- At the beginning of a read cycle, move wait low
if ab_wait_n_l = '1' and ab_rd = '1' and rd_delay(0) = '0' then
ab_wait_n_l <= '0';
end if;
-- At the beginning of any cycle, if the ss-master part is busy,
wait
if (ab_wait_n_l = '1' and (ab_rd = '1' or ab_wr = '1')) and
(wb_cyc_l = '1')
then
ab_wait_n_l <= '0';
end if;
-- At the end of an ss-master cycle, remove wait
if wb_ack = '1' and (
(wb_we_l = '1' and ab_rd = '0') or -- no pending read
wb_we_l = '0') -- was a read operation
then
ab_wait_n_l <= '1';
end if;
end if;
end process;
-- Generate handshake-type wait signal
a_waiths_gen: process(wb_rst_i,wb_clk_i)
begin
if (wb_rst_i = '1') then
ab_waiths_l <= '0';
elsif wb_clk_i'EVENT and wb_clk_i = '1' then
-- Write handling
if wb_cyc_l = '0' and ab_wr = '1' then
ab_waiths_l <= '1';
end if;
if wb_ack = '1' and ab_waiths_l = '1' then
ab_waiths_l <= '0';
end if;
-- Read handling
if wb_ack = '1' and ab_rd = '1' then
ab_waiths_l <= '1';
end if;
if wb_cyc_l = '0' and ab_rd = '0' and ab_wr = '0' and
wr_delay(wr_delay'HIGH) = '0'
then
ab_waiths_l <= '0';
end if;
end if;
end process;
-- connect local signals to external pins
wb_cyc_o <= wb_cyc_l;
wb_we_o <= wb_we_l;
ab_dat <= wb_dat_reg when ab_rd = '1' else (others => 'Z');
-- On post-layout simulation it turned out that the data is not stable
upon
-- the raising edge of these wait signals. So we delay the raising edge
with one-half clock
delay_wait: process(wb_clk_i)
begin
if wb_clk_i'EVENT and wb_clk_i = '0' then
ab_wait_n_l_delayed <= ab_wait_n_l;
ab_waiths_l_delayed <= ab_waiths_l;
end if;
end process;
ab_wait_n <= ab_wait_n_l and ab_wait_n_l_delayed;
ab_waiths <= ab_waiths_l and ab_waiths_l_delayed;
end xilinx;
Article: 62521Glen, http://www.panasonic.com/industrial/battery/oem/images/pdf/Panasonic_LiIon_Charging.pdf As I said, just look it up. Austin Glen Herrmannsfeldt wrote: > "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message > news:3FA28A84.AAA1FE7A@xilinx.com... > > Nial, > > > > You will not damage or over-charge the battery if you follow the > > manufacturer's recommendations. > > > > It is amazing how few engineers have even looked at, read, and used the > data > > sheets for a battery. > > > > It is a component just like any other: study it, learn its > characteristics, > > and then design it in. > > I don't know the details, but Li ion is very different from NiCd. Some > years ago all we had was NiCd, charged at 0.1C (take the milliamp-hour > rating, divide by 10, and charge at that many milliamps) for 14 hours. That > was all anyone needed to know. > > Now there are so many different battery chemistries, each with its own > charging characteristics and discharge characteristics. > > -- glenArticle: 62522
Christopher Fairbairn wrote:
> For example the line
>
> WB_CLK_O <= not e_clk;
>
> The problem is the HC11 reads/writes on the falling edge,
> while the wishbone interface does it on the rising edge... But isn't this
> inversion I've done inheriently evil or "bad design"?
Consider synchronizing the interface to a faster fpga clock and generate
your own synchronous read and write strobes in just the right places.
> Perhaps the systhensis tools are smart enough to mean I
> don't have to worry about it..
They aren't.
>
> I am also interested with respect to how I've attempted to implement the
> tri-stateable interface for the 8bit data port to the HC11's bus. Am I
> heading in the right direction in this respect?
Looks reasonable for a first cut.
You have to compare your sim waveforms to the H11 and wishbone data sheets.
Consider making an oe signal to drive data Z between cycles.
I don't know the interfaces, but
WB_STB_O <= cs;
is suspect.
Normally cs lasts for multiple ticks,
the write strobe is one tick, somewhere in the middle.
> One thing this project has highlighted is the need for me to learn more
> about writing better testbenches... I totally agree with the comments I've
> seen in this newgroup about newbies starting out with a simulator and no
> physical hardware. I sure wish I had started out that way :-)
It's not too late.
> PS: Can anyone suggest a good book on Simulation, in particular with
> relation to VHDL? I've identified this as an area where I'm particular
> weak, and as an area where improvements would make progress a bit smoother.
You already know how to run the simulator,so get a copy of
Ashenden's guide to vhdl as a language reference, and get busy.
Consider adopting a synchronous testbench style:
http://groups.google.com/groups?q=oe_demo
> For example how do you go about reading in stimulius from a file so I don't
> have to hardcode in bus transactions in my testbench, and can instead
> simply read them in from a file containing "read 0x8000, write 0x7000" or
> the equivalent...
Use vhdl procedures to do this.
Using an intermediate text file makes it harder, not easier.
-- Mike Treseler
Article: 62523"kryten_droid" <kryten_droid@ntlworld.com> wrote in message news:DHxob.1172$yH4.711@newsfep1-gui.server.ntli.net... > I have an XC2S300E-pq08 which the data sheet says has 146 user I/O max. > > However, the PAR says: > > Number of bonded IOBs: 144 out of 142 101% > > There are still quite a few I/O pins left on my dev board. > > I'm puzzled that it seems I can use any I/O pins but > less than all of them at the same time. > > Is this the case or am I missing something fundamental? > > Thanks in advance, There are four dedicated clock pins. Regrads, Andras TantosArticle: 62524
I writing VHDL for a Xilinx Virtex-II Pro FPGA application, and software for its embedded PowerPC. The PowerPC doesn't have hardware floating point, and floating point emulation in software is too slow for my purpose. So, I'm looking for a way to add floating point in the FPGA fabric through VHDL or black boxes. I need IEEE floating point operations such as add, subtract, multiply, divide. I also need some math functions like sine, cosine, square root, etc. Is there a (free) standard package in VHDL that I can use for this? Third party support? I'm a newbie on a budget, so I'm looking for the cheapest, quickest solution. Any advice would be appreciated. Ed.
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