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
jetq88 wrote: > hello all, > > I have experience with ARM microcontroller in C/C++ programming, now > job function force me to have to expand my skill into FPGA, don't know > anyone out there in the same shoes having experience with this > transition, which Hardware language, VHDL or Verilog HDL or System C or > Handle C will make my life easier? I guess if you master one, it > should make you quicker to jump into another one, but for me with > limited hardware experience, which one can make this transition much > smoother. > > thanks > > jet > I'm in the same boat, however my reasons for wanting to get into FPGA use are more personal as opposed to required by the company. I chose VHDL almost automatically. Verilog I recall suffered from complications when the project gets very big -- it isn't as strong as VHDL in putting separate components together to form a whole. Note I'm completely unfamiliar with Verilog, and the complaint above came from some other source. I've heard lots of complaints about VHDL and I've got a few of my own. I'm just barely getting the hang of it, I can read it better than I can write it. I'm still trying to work out a style of my own. However it just seems to me time spent getting to know VHDL won't be wasted. Important thing -- don't give up! It may seem very frustrating at first but remember everything will get worked out in the end. My big fear was something like "Oh god, this is just so ugly. I can't see myself having to do ugly things all the time...forget it." In the end it's not really ugly...just unfamiliar. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108451
Weng Tianxiang wrote: > Hi David, > I never use DOS commands and all options are accessable through Xilinx > ISE window system so that I don't know how to answer any questions > about it. > > Weng Aha! So your list was just describing your own way of development, it wasn't meant as advice as to how best to do development. Thanks-- Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108452
In the days of 5v ttl signals on boards, active low signals had more noise immunity than active high signals (assuming it is worse for noise to make a false signal true, than the other way around). Now, with 3.3V signals, there is a very small difference in the noise margings between levels, and with 2.5V logic and below, there is none. If you consider 5V TTL logic, most drivers can be pulled up to to nearly 5V with a resistor, giving nearly 3 volts of headroom before falling below the minimum high-level threshold at the receiver. With a low driven signal, at 0.4V, it is hard to put a big enough resistor (small enough value) on the signal to pull it below 0.2 volts or so (otherwise the driver would not be able to drive the signal high against such a resistor). So it would only take a noise spike of 0.6 V to get above the maximum low threshold at the receiver, where, under just the wrong circumstances (remember Murphy!), it could be considered a high level input. Andy Roger wrote: > Why RESET signals are always active low? I understand that active low > resets are immune to noise, but could someone explain in detail? > > Also > > How does Power on Rest Work? > > ThanksArticle: 108453
"PeteS" <PeterSmith1954@googlemail.com> wrote in message news:1157987644.057824.253860@b28g2000cwb.googlegroups.com... And besides, all work and no play makes a dull person (and a dull employee too ;) Is there any other sort of employee?Article: 108454
I should add that relying on RC networks driving digital inputs for power up resets is not a reliable practice, especially with fast, low voltage logic. The slow rise time causes high power dissipation, noise, and multiple transitions in and out of reset, leading to eratic operation. I have also seen cases where a 2.5V processor actually executed random code when VCC > 1.0 V, which was lower than the reset circuit could guarantee a valid output. Purpose-made power up reset circuits that guarantee reset outputs down to VCC >= 0.8V are necessary in such cases. Andy Andy wrote: > In the days of 5v ttl signals on boards, active low signals had more > noise immunity than active high signals (assuming it is worse for noise > to make a false signal true, than the other way around). Now, with > 3.3V signals, there is a very small difference in the noise margings > between levels, and with 2.5V logic and below, there is none. > > If you consider 5V TTL logic, most drivers can be pulled up to to > nearly 5V with a resistor, giving nearly 3 volts of headroom before > falling below the minimum high-level threshold at the receiver. With a > low driven signal, at 0.4V, it is hard to put a big enough resistor > (small enough value) on the signal to pull it below 0.2 volts or so > (otherwise the driver would not be able to drive the signal high > against such a resistor). So it would only take a noise spike of 0.6 V > to get above the maximum low threshold at the receiver, where, under > just the wrong circumstances (remember Murphy!), it could be considered > a high level input. > > Andy > > > Roger wrote: > > Why RESET signals are always active low? I understand that active low > > resets are immune to noise, but could someone explain in detail? > > > > Also > > > > How does Power on Rest Work? > > > > ThanksArticle: 108455
Peppe wrote: > Which is the difference between Functional and Post-Synthesis Simulation? > Why should I do both simulation? > > Thanks > > Peppe The basic difference between functional and post-synthesis simulation is that functional simulation only check the behaviour of your design. It does not point out any race conditions that might occur in your design. Post-synthesis simulation is the simulation of your design after it has been synthesized, which means, that your design has been converted to gates and takes timing(propagation delays, setup and hold delays) into account. This simulation sheds light into race conditions or any other timing issues that might exist in your design which werent apparent in the behaviour simulation. Personally, I perform behavioural(functiona) simulation to check if the design is working properly and then perform timing(post-synthesis) simulation to check for timing violations, race conditions, etc. Hope this helpsArticle: 108456
Hi All, What do people think of my idea from my post of Sun, Sep 10 2006 7:25 pm? I have a description of what I am doing, followed by a question: >I am doing a lot of simultaneous "xor"s of >different bit ranges of 128-bit "words" and using >a function that uses a function (i.e., >combinatorial logic) and I'm doing that >simultaneously as input to signals that are then >"xor"-ed. These are done after each clock cycle, >when initial signals are updated. That is, when >these initial signals are updated in a process at >the rising edge of my clock, then I have >additional signals that should just be updated >because the data has changed. I'm not using any >sensitivity list or any clock cycle for them. >These assignments should cause signals to change, >which cause the next set of signals to change, in >about three steps, with ranges of bits being >processed in parallel (and mixed, which is why I >have to get into bit ranges). Finally, signals >named "_next" are updated, then the next clock >cycle is awaited at which time the original >signals are updated from the "_next" signals. >Based on my experience so far in which I got into >trouble at the synthesize and translate stage due >to not having a clock on my ROM, do you think >putting clocks on everything would be the thing to >try? I am trying this. Does anyone have some (simple to them) samples of VHDL code along these lines that succeed in a Xilinx FPGA? Best regards, -JamesArticle: 108457
"jetq88" <jetq5188@gmail.com> wrote in message news:1157987349.644693.118260@e3g2000cwe.googlegroups.com... > hello all, > > I have experience with ARM microcontroller in C/C++ programming, now > job function force me to have to expand my skill into FPGA, don't know > anyone out there in the same shoes having experience with this > transition, which Hardware language, VHDL or Verilog HDL or System C or > Handle C will make my life easier? I guess if you master one, it > should make you quicker to jump into another one, but for me with > limited hardware experience, which one can make this transition much > smoother. > > thanks > > jet > Generally Europe uses VHDL and the US uses Verilog. I would suggest you use the one which is most likely to be used by your potential future employers.Article: 108458
Hello Toto, Please open the stp file and click on the SignalTap II Data tab to have the waveform to be exported visible in the window. Go to menu File and select Export. The dialog box as described in the help shows up. If you see the option to export the testbench file, you must've had the Vector Waveform File (vwf) editor open and fwith the window focus at that time. The Waveform File Editor is a different editor from SignalTap II Logic Analyzer editor window. Hope this helps, Subroto Datta Altera Corp. Thank you. tthurnherr@gmail.com wrote: > Hi there > I'm trying to export a waveform from the quartus 2 web edition. In the > quartus 2 help, there's a nice explanation how to do that: > > >Export Dialog Box (SignalTap II Logic Analyzer) > > > >-------------------------------------------------------------------------------- > >You open this dialog box by clicking Export on the File menu. > > > >Exports the current SignalTap II waveform data to a Comma-Separated Value File (.csv), >Vector Table Output File (.tbl), Value Change Dump File (.vcd), Vector Waveform File (.vwf), >JPEG File Interchange Format (.jpg), or Bitmap File (.bmp). > > Unfortunately, when i execute the described action, I can only export > VHDL testbench files (*.vht) and Verilog testbench files (*.vt). > > Can anybody tell me if this is because of the licence, or if i'm doing > something else wrong? > > My version is 6.0 build 202 SJ Web Edition, with service pack 1 > installed. > > Thanks a lot and have a nice day > > > totoArticle: 108459
Fred wrote: > "jetq88" <jetq5188@gmail.com> wrote in message > news:1157987349.644693.118260@e3g2000cwe.googlegroups.com... > >>hello all, >> >>I have experience with ARM microcontroller in C/C++ programming, now >>job function force me to have to expand my skill into FPGA, don't know >>anyone out there in the same shoes having experience with this >>transition, which Hardware language, VHDL or Verilog HDL or System C or >>Handle C will make my life easier? I guess if you master one, it >>should make you quicker to jump into another one, but for me with >>limited hardware experience, which one can make this transition much >>smoother. >> >>thanks >> >>jet >> > > > Generally Europe uses VHDL and the US uses Verilog. I would suggest you use > the one which is most likely to be used by your potential future employers. > > There's enough of both (at least in the US) that unless you're trying for a specific employer it would be a good idea to learn one thoroughly, and learn at least a little bit of the other. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Posting from Google? See http://cfaj.freeshell.org/google/ "Applied Control Theory for Embedded Systems" came out in April. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 108460
John Woodgate wrote: > > Who did that? I'm not sure. All caps gives me a splitting headache, so I don't even read them anymore. -- Service to my country? Been there, Done that, and I've got my DD214 to prove it. Member of DAV #85. Michael A. Terrell Central FloridaArticle: 108461
are you sure you have all the pin assignments/connections between plb_temac and hard_temac and such set up properly for the board ? here are the relevant portions of the system.mhs and system.ucf files that i am using (for the same V4FX12 mini module board with the gig phy) --- system.mhs PORT hard_temac_0_GMII_RX_CLK_0_pin = hard_temac_0_GMII_RX_CLK_0, DIR = I PORT hard_temac_0_GMII_RX_DV_0_pin = hard_temac_0_GMII_RX_DV_0, DIR = I PORT hard_temac_0_GMII_RX_ER_0_pin = hard_temac_0_GMII_RX_ER_0, DIR = I PORT hard_temac_0_GMII_RXD_0_pin = hard_temac_0_GMII_RXD_0, DIR = I, VEC = [7:0] PORT hard_temac_0_GMII_TX_CLK_0_pin = hard_temac_0_GMII_TX_CLK_0, DIR = O PORT hard_temac_0_GMII_TX_EN_0_pin = hard_temac_0_GMII_TX_EN_0, DIR = O PORT hard_temac_0_GMII_TX_ER_0_pin = hard_temac_0_GMII_TX_ER_0, DIR = O PORT hard_temac_0_GMII_TXD_0_pin = hard_temac_0_GMII_TXD_0, DIR = O, VEC = [7:0] PORT hard_temac_0_GTX_CLK_0_pin = hard_temac_0_GTX_CLK_0, DIR = I PORT hard_temac_0_MDC_0_pin = hard_temac_0_MDC_0, DIR = O PORT hard_temac_0_MDIO_0_pin = hard_temac_0_MDIO_0, DIR = IO PORT plb_temac_0_PhyResetN_pin = plb_temac_0_PhyResetN, DIR = O PORT hard_temac_0_MII_TX_CLK_0_pin = hard_temac_0_MII_TX_CLK_0, DIR = I .... BEGIN hard_temac PARAMETER INSTANCE = hard_temac_0 PARAMETER HW_VER = 3.00.a BUS_INTERFACE V4EMACDST0 = plb_temac_0_V4EMACSRC PORT GMII_RX_CLK_0 = hard_temac_0_GMII_RX_CLK_0 PORT GMII_RX_DV_0 = hard_temac_0_GMII_RX_DV_0 PORT GMII_RX_ER_0 = hard_temac_0_GMII_RX_ER_0 PORT GMII_RXD_0 = hard_temac_0_GMII_RXD_0 PORT GMII_TX_CLK_0 = hard_temac_0_GMII_TX_CLK_0 PORT GMII_TX_EN_0 = hard_temac_0_GMII_TX_EN_0 PORT GMII_TX_ER_0 = hard_temac_0_GMII_TX_ER_0 PORT GMII_TXD_0 = hard_temac_0_GMII_TXD_0 PORT GTX_CLK_0 = hard_temac_0_GTX_CLK_0 PORT MDC_0 = hard_temac_0_MDC_0 PORT MDIO_0 = hard_temac_0_MDIO_0 PORT REFCLK = sys_clk_s PORT RESET = plb_temac_0_Emac_Reset PORT MII_TX_CLK_0 = hard_temac_0_MII_TX_CLK_0 END BEGIN plb_temac PARAMETER INSTANCE = plb_temac_0 PARAMETER HW_VER = 3.00.a PARAMETER C_BASEADDR = 0x80400000 PARAMETER C_HIGHADDR = 0x8040ffff PARAMETER C_PLB_CLK_PERIOD_PS = 10000 PARAMETER C_DMA_TYPE = 1 PARAMETER C_RX_DRE_TYPE = 0 PARAMETER C_TX_DRE_TYPE = 0 PARAMETER C_RXFIFO_DEPTH = 65536 PARAMETER C_TXFIFO_DEPTH = 65536 BUS_INTERFACE MSPLB = plb BUS_INTERFACE V4EMACSRC = plb_temac_0_V4EMACSRC PORT IP2INTC_Irpt = plb_temac_0_IP2INTC_Irpt PORT PhyResetN = plb_temac_0_PhyResetN PORT Emac_Reset = plb_temac_0_Emac_Reset END --- system.ucf Net hard_temac_0_GMII_RX_CLK_0_pin LOC=W11 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RX_DV_0_pin LOC=J6 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RX_ER_0_pin LOC=H1 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<0> LOC=J5 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<1> LOC=K3 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<2> LOC=J4 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<3> LOC=K4 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<4> LOC=M6 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<5> LOC=L2 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<6> LOC=K1 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_RXD_0_pin<7> LOC=K2 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TX_CLK_0_pin LOC=M2 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TX_EN_0_pin LOC=N2 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TX_ER_0_pin LOC=P1 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<0> LOC=M4 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<1> LOC=N4 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<2> LOC=L1 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<3> LOC=M1 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<4> LOC=P2 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<5> LOC=N5 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<6> LOC=P4 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GMII_TXD_0_pin<7> LOC=P5 | IOSTANDARD = LVCMOS33; Net hard_temac_0_MII_TX_CLK_0_pin LOC=Y5 | IOSTANDARD = LVCMOS33; Net hard_temac_0_GTX_CLK_0_pin LOC=W9 | IOSTANDARD = LVCMOS33; Net hard_temac_0_MDC_0_pin LOC=J3 | IOSTANDARD = LVCMOS33; Net hard_temac_0_MDIO_0_pin LOC=N3 | IOSTANDARD = LVCMOS33; Net plb_temac_0_PhyResetN_pin LOC=M3 | IOSTANDARD = LVCMOS33; --- works for me ! note the connection from the plb_temac to the reset pin on the PHY, if this is missing you probably won't get a link... -rimas Benedikt Wildenhain wrote: > Hello, > > I am using the XilinX Virtex 4 FX 12 Evaluation Kit and want to get > ethernet working (it will have to do some IP networking stuff). The board > is equipped with an mii-interface so usign hard_temac and plb_temac > should be enough (or am I wrong here?). I programmed the FPGA with using > these IP cores (and those which the BSB preselected), but the ethernet > switch I connected to the board does not recognize anything. Do I make any > mistake? Or do I first need to get some software running on the > integrated ppc which somehow initializes the ethernet interface? >Article: 108462
Hi Antti, I understood from our local FAE, it should become available very soon as Lattice is building inventory. The kit should be quite complete - no indication of price however. The FAE told me that some new things are being tested for compliancy (like SATA) and one can expect full support for this as well in the near future. Luc On 11 Sep 2006 07:20:10 -0700, "Antti" <Antti.Lukats@xilant.com> wrote: >Hi > >http://www.latticesemi.com/products/developmenthardware/fpgafspcboards/scpciexpressx1evaluationb.cfm > >I wonder if that board is available and if it really supports SATA as >it advertized to support? > >On the website there is no price information what usually is bad news >regarding actual board availability :( > >AnttiArticle: 108463
> >I am doing a lot of simultaneous "xor"s of
> >different bit ranges of 128-bit "words" and using
> >a function that uses a function (i.e.,
> >combinatorial logic) and I'm doing that
> >simultaneously as input to signals that are then
> >"xor"-ed. These are done after each clock cycle,
> >when initial signals are updated. That is, when
> >these initial signals are updated in a process at
> >the rising edge of my clock, then I have
> >additional signals that should just be updated
> >because the data has changed. I'm not using any
> >sensitivity list or any clock cycle for them.
> >These assignments should cause signals to change,
> >which cause the next set of signals to change, in
> >about three steps, with ranges of bits being
> >processed in parallel (and mixed, which is why I
> >have to get into bit ranges). Finally, signals
> >named "_next" are updated, then the next clock
> >cycle is awaited at which time the original
> >signals are updated from the "_next" signals.
It sounds like relatively straightforward logic and registers. There
are absolutely no issues with using any design language to implement
this.
> >Based on my experience so far in which I got into
> >trouble at the synthesize and translate stage due
> >to not having a clock on my ROM, do you think
> >putting clocks on everything would be the thing to
> >try?
Not unless the outputs are required to be clocked for some other reason
no clock is required. A couple reasons why you might want to clock the
outputs would be...
- More consistent timing on when the outputs become available (i.e. the
clock to output delay generally doesn't change much if the final
outputs are clocked)
- No glitching on the outputs. The output of a flip flop will either
change or remain the same for the entire clock cycle whereas the output
of combinatorial logic implemented inside an FPGA might glitch during
the propogation delay while the new output value is being computed.
That doesn't imply that clocked are 'better' or 'worse' you just need
to be aware of what will come out. As another very general statement,
there is usually absolutely no need for internal signals to be clocked
except to improve clock cycle performance. Since you've provided no
information regarding what speed you need to run at, I'd say that there
is no speed issue at present.
>
> I am trying this. Does anyone have some (simple to
> them) samples of VHDL code along these lines that
> succeed in a Xilinx FPGA?
Not sure exactly what you were trying to describe but my interpretation
is that is something of the form...
y <= Fun1(Fun2(X1(100 downto 83)) xor X2(17 downto 0);
where Fun1 and Fun2 are your 'function of a function', X1 and X2 are
some inputs of some sort and you're Xor-ing them together. I'm sure I
didn't guess right, but on the off chance that it is correct then 'yes'
the above line of code will work just fine for what you're trying to
do. If you want a clocked output y then
process(Clock)
begin
if rising_edge(Clock) then
y <= Fun1(Fun2(X1(100 downto 83)) xor X2(17 downto 0);
end if;
end process;
All of this will work you need to sit down and write the logic
equations for whatever it is you're trying to implement there shouldn't
be any need for any trial and error.
KJ
Article: 108464morpheus wrote: > Peppe wrote: > > Which is the difference between Functional and Post-Synthesis Simulation? > > Why should I do both simulation? > > > > Thanks > > > > Peppe > > The basic difference between functional and post-synthesis simulation > is that functional simulation only check the behaviour of your design. > It does not point out any race conditions that might occur in your > design. > Post-synthesis simulation is the simulation of your design after it has > been synthesized, which means, that your design has been converted to > gates and takes timing(propagation delays, setup and hold delays) into > account. This simulation sheds light into race conditions or any other > timing issues that might exist in your design which werent apparent in > the behaviour simulation. It might shed light but it most likely will not since there is no expectation that the simulation will hit any of the corner conditions. Furthermore, timing simulations do not take into account any sort of variability of timing (i.e. min delay here, max delay there it simply uses all min, or all max or all typ). While you can argue that on a single chip you probably won't have a mix of mins and max you can't argue that there will be no variation (i.e. say 80% - 130% of typical). To check for correct timing you perform static timing analysis which does not require any simulation. > Personally, I perform behavioural(functiona) simulation to check if the > design is working properly and then perform timing(post-synthesis) > simulation to check for timing violations, race conditions, etc. I'd suggest you perform static timing analysis instead...it is typically an output report of the synthesis operation. KJArticle: 108465
Hello, Recently, I have been trying to simulate my system to verify that the pieces are working correctly in my EDK project. In order to do this, I need to use the SmartModel simulation tools for ModelSim 6.1e. I've read through all of Xilinx's documentation and have set up the modelsim.ini file correctly, but when I run the simulation, everything hangs. There are no calls to the BRAM to fetch code for execution. The only thing I get that might be a part of the problem is the following warnings: # ** Warning (SmartModel): # Model is being requested to run at a finer resolution than necessary. Anyone been able to do a system level simulation using SimGen and EDK? JonArticle: 108466
It should go without saying, but the EDK version is 8.1i with the latest 8.1 WebPackArticle: 108467
On 2006-09-11, Antti <Antti.Lukats@xilant.com> wrote: > BTW there is no SYNTHESIZE thing in the or1200_defines.v :( > there is something about xilinx memories and the synthese really > uses xilinx RAMB16 prims, but what else to check I dont know. Oops, I think I should be a bit embarrased. I guess that we added it to our version of or1200 used in teaching. `include "shamed_face.v" I guess :) Sorry for making you look for something which wasn't there. Anyway, what I can confirm is that we have successfully synthesized an older version of OR1200 with both ISE 7.1 and 8.1. The exact version can be found on the course homepage at http://www.da.isy.liu.se/courses/tsea02/labs.html. Lab1 is a small system with the UART and parport missing (the students are supposed to implement those to get familiar with wishbone and verilog) whereas lab2-4 is a larger system. It should be possible to trim it down to a smaller system if necessary. /AndreasArticle: 108468
Andy wrote: > In the days of 5v ttl signals on boards, active low signals had more > noise immunity than active high signals (assuming it is worse for noise > to make a false signal true, than the other way around). Now, with > 3.3V signals, there is a very small difference in the noise margings > between levels, and with 2.5V logic and below, there is none. > > If you consider 5V TTL logic, most drivers can be pulled up to to > nearly 5V with a resistor, giving nearly 3 volts of headroom before > falling below the minimum high-level threshold at the receiver. With a > low driven signal, at 0.4V, it is hard to put a big enough resistor > (small enough value) on the signal to pull it below 0.2 volts or so > (otherwise the driver would not be able to drive the signal high > against such a resistor). So it would only take a noise spike of 0.6 V > to get above the maximum low threshold at the receiver, where, under > just the wrong circumstances (remember Murphy!), it could be considered > a high level input. > > Andy > > > Roger wrote: >> Why RESET signals are always active low? I understand that active low >> resets are immune to noise, but could someone explain in detail? >> >> Also >> >> How does Power on Rest Work? >> Many signals in the discrete-logic days were active low, and still are, out of habit. Most decoder chips, for example, have active-low outputs. SRAM chips therefore have active-low enable inputs, to work with them. The reason actually predates TTL. Before TTL was DTL (diode-transistor logic), in which a wired-AND was the norm: that is, 2 or more transistors to ground, & a common pullup resistor. So the Low output impedance (a saturated transistor) is much lower than the High output (the resistor). Better noise tolerance.Article: 108469
I want to create a 1152 by 6 bit rom and I want to use a bram. It can be clocked or not clocked, but I'd prefer not clocked. Can someone point me to a template? Something like this takes a long time to synthesize... library IEEE; use IEEE.STD_LOGIC_1164.ALL; use ieee.numeric_std.all; entity fontrom is port ( addr : in unsigned ( 10 downto 0); data : out std_logic_vector ( 5 downto 0) ); end fontrom; architecture rtl of fontrom is begin process ( addr) begin case addr is when "00000000000" => data <= "000000"; when "00000000001" => data <= "000000"; when "00000000010" => data <= "000000"; when "00000000011" => data <= "000000"; when "00000000100" => data <= "000000"; when "00000000101" => data <= "000000"; when "00000000110" => data <= "000000"; ... when "10001111100" => data <= "111111"; when "10001111101" => data <= "111111"; when "10001111110" => data <= "111111"; when "10001111111" => data <= "111111"; when others => data <= "00000"; end case; end process; end rtl; Thanks-- Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108470
David Ashley wrote:
> I want to create a 1152 by 6 bit rom and I want to use
>[cut]
I found this thread...
http://groups.google.com/group/comp.lang.vhdl/browse_thread/thread/9d83482446592315/cb311613c24c9d31?lnk=st&q=this_rom+small_rom+a_length&rnum=3#cb311613c24c9d31
Tues Nov 13 2001 Mike Treseler suggests something, see my attempt below.
This synthesizes quickly but doesn't seem to use a BRAM, it
uses 400+ LUTs to do it...want to use BRAMS as they're
unused, and LUT's are in short supply...
-Dave
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity fontrom is
port (
addr : in unsigned ( 10 downto 0);
data : out std_logic_vector ( 5 downto 0)
);
end fontrom;
architecture rtl of fontrom is
type small_rom is array (0 to 1151)
of std_logic_vector(5 downto 0);
constant this_rom : small_rom :=
(
0 => "000000",
1 => "000000",
2 => "000000",
3 => "000000",
4 => "000000",
...
1143 => "111111",
1144 => "111111",
1145 => "111111",
1146 => "111111",
1147 => "111111",
1148 => "111111",
1149 => "111111",
1150 => "111111",
1151 => "111111",
others => "000000"
);
begin
data <= this_rom(to_integer(addr));
end architecture rtl;
--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
Article: 108471On 2006-09-11, David Ashley <dash@nowhere.net.dont.email.me> wrote: > I want to create a 1152 by 6 bit rom and I want to use > a bram. It can be clocked or not clocked, but I'd prefer > not clocked. Can someone point me to a template? There's a whole PDF of them called "xst.pdf" which you can google. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 108472
Ben Jackson wrote: > On 2006-09-11, David Ashley <dash@nowhere.net.dont.email.me> wrote: > >>I want to create a 1152 by 6 bit rom and I want to use >>a bram. It can be clocked or not clocked, but I'd prefer >>not clocked. Can someone point me to a template? > > > There's a whole PDF of them called "xst.pdf" which you can google. > Thank you very much! That's what I was after. Well I'll be busy reading for a while... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108473
Hi, I am porting my design from ASIC to FPGA, but I found the timing in FPGA is very bad. What I konw is to set up the clock constraints, I don't know how to add other constraints. Can any boby give me some hints? thanks very much. I use Altera clone II. skyworldArticle: 108474
morpheus wrote: > Peppe wrote: > >>Which is the difference between Functional and Post-Synthesis Simulation? >>Why should I do both simulation? >> >>Thanks >> >>Peppe > > > The basic difference between functional and post-synthesis simulation > is that functional simulation only check the behaviour of your design. > It does not point out any race conditions that might occur in your > design. > Post-synthesis simulation is the simulation of your design after it has > been synthesized, which means, that your design has been converted to > gates and takes timing(propagation delays, setup and hold delays) into > account. This simulation sheds light into race conditions or any other > timing issues that might exist in your design which werent apparent in > the behaviour simulation. > Personally, I perform behavioural(functiona) simulation to check if the > design is working properly and then perform timing(post-synthesis) > simulation to check for timing violations, race conditions, etc. > Hope this helps > Timing simulation by itself does not guarantee that you will catch all timing problems. You only catch the timing problems that match the timing of the test your are running. In addition, the delays in the model are generally the maximum delay, not the worst case (meaning minimum or maximum depending on the circumstance). If you rely on a post-par simulation to determine timing compliance, you are setting yourself up for a lot of grief down the line. You will get more complete timing coverage by doing a proper timing analysis on the design. For synchronous designs, that is pretty easy to accomplish using the tools provided with all of the major FPGA place and route tools. The post-PAR simulation is really only useful for catching the very rare mistake by the PAR tools, or catching something that fell under a multi-cycle constraint when it didn't belong there.
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