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
On Oct 16, 10:32=A0pm, Nathan Bialke <nat...@bialke.com> wrote: > On Oct 16, 10:08=A0am, aleksa <aleks...@gmail.com> wrote: > > > On Oct 16, 5:12=A0pm, Nathan Bialke <nathan.bia...@gmail.com> wrote: > > Here, WR is used as GCK and also as signal: > > I would suggest not doing that. > > > > > > > > > -- main CPU writes a command to slave CPU, via FPGA > > > =A0 =A0 =A0 =A0 if rising_edge(WR) and <other coditions, like address..= > then > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 COMMAND <=3D DBUS; =A0 -- register comm= and > > =A0 =A0 =A0 =A0 end if; > > > -- slave CPU ready flag > > > =A0 =A0 =A0 =A0 if WR=3D'0' and <same other coditions..> then > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '0'; =A0 -- write detected, = signal slave CPU is busy > > > =A0 =A0 =A0 =A0 elsif rising_edge(SLAVE_CPU_ACK) then > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 READY <=3D '1'; > > =A0 =A0 =A0 =A0 end if; > > > (I need this READY signal to be edge sensitive, > > not level, since slave CPU is really slow.) > > I would suggest that you don't want to do your bus interface this way. > The way you are following is fraught with danger. There are also much > easier ways to do what I think you want to do. Specifically, if the > slave CPU is really slow, make a synchronous interface yourself by > synchronizing the CPU signals into the FPGA timing domain. Why is it dangerous? How would you do it? As I see it, it is a register with asynchronus reset. The XILINX people say that it is more resource consuming, but they dont say that it wont work. The speed of the slave CPU is important in this example beacuse this may happen if the level was tested and not edge: 1. main CPU writes a command. 2. slave CPU (which is 100 times slower) responds to command and then sets SLAVE_CPU_ACK to '0'. 3. main CPU tests the status of the slave to see if it is ready. 4. since it is ready, the main CPU writes another command before the slave has set the SLAVE_CPU_ACK back to '1' with the result of the new command being lost. I have several examples like that in my VHDL code: This one, for example, is not speed critical: if (CS=3D'0' and RD=3D'0' and ADDR=3D"1100") or (RESET=3D'0') then IRQ <=3D= '0'; elsif falling_edge(SLAVEIRQ) then IRQ <=3D '1'; end if; (Slave can send me an IRQ and I can ACK it by reading the slave's status or by hard reset) Then I have this: if SLAVECS=3D'0' and SLAVEADDR=3D"1011" then REGISTER <=3D SHIFTIN; elsif rising_edge(WR) and CS=3D'0' and ADDR=3D"1111" then REGISTER <=3D DBUS; end if; (The main CPU can write to REGISTER, and also the slave can write it). (after shifting data in serially to SHIFTIN register, which is not shown) > > Another example is a bi-dir data bus (RD is also used as GCK, > > elsewhere): > > > =A0 =A0 =A0 =A0 DBUS <=3D DATAOUT when RD=3D'0' else "ZZZZZZZZ"; > > > ISE gives warning (again, it works on Spartan 3): > > > MapLib:95 - IBUF symbol "RD_IBUF" (output signal=3DRD_IBUF1) > > is promoted to indicate the use of GCLKIOB site. > > I would suggest that your design probably isn't working in a Spartan-3 > as well as you think. Using asynchronous control signals as clocks is > not going to work particularly well in any FPGA.- Hide quoted text - > > - Show quoted text - How else can I make a bi-dir data bus? The only signals I can monitor are CS=3D0, RD=3D0 and correct address bus (CS and ABUS not shown in the above code). I can get by the whole thing (ie. ISE doesn't complain) if I connect a RD and WR to two pins, a GCK pin and a IOB pin. Then I call them cRD, cWR, sRD and sWR (c=3Dclock, s=3Dsignal) and use c or s version where appropriate. And yes, I haven't tested anything on a real hardware yet.Article: 135826
CPLD design can be quite challenging due to the restricted logic ressources, especially flipflops. However in real life, your mentioned projects should be done in FPGA's, a small 50k Spartan3/A/AN should fit plenty of tetris games and clocks, since during a real project, nobody has the time to think about partitioning or saving logic ressources like flipflops etc. However using CPLD's can be fun, and a student can learn a lot about logic optimisation (speed versus area). Since CPLD's (as FPGA's) can be clocked with high frequency (100MHz-300MHz), nested and multiplexed logic can improve ressource efficiency. Also the available produkt term pool and the array inputs can be used up to 100%, if some nodes in every array are used for different purposes, which are not needed concurrently. However this design practice is very error prone, but it's a game, isn't it ? In general bitserial processing is the way to go in low ressource CPLD's. A small serial CPU can be built with the mentioned SPI SRAM, but FRAM would be more suitable. Since flipflops are rare in CPLD's, external shift regs like HCT595 or HCT165 can be used to hold CPU registers. Also ancient 64kx1 or 256kx1 DRAMs can be used as CPU memory. The 74HCT7731 is also still available (yet not cheap), a 4x64bit shift register, which can be used as a ring buffer for various CPU registers. I often connect 7-segment leds to HC595 without a decoder, a cheap and intersting spi led display. If efficiency is not important, also parallel CPU's can be implemented with CPLD's. An 8bit PIC or similar architecture is a nice student project. The ROM (Flash) can be implemented in a separate CPLD. The SRAM can also be swapped out to a CPLD (built from flipflops), but as in the ROM example, only a few bytes can be stored. This demonstrates quite good, that separate memory chips are often required in modern embedded systems. MIKE -- www.oho-elektronik.de OHO-Elektronik Michael Randelzhofer FPGA und CPLD Mini Module Klein aber oho ! Kontakt: Tel: 08131 339230 mr@oho-elektronik.de Usst.ID: DE130097310Article: 135827
> How else can I make a bi-dir data bus? > The only signals I can monitor are CS=0, RD=0 and > correct address bus (CS and ABUS not shown in the above code). > > I can get by the whole thing (ie. ISE doesn't complain) if I connect > a RD and WR to two pins, a GCK pin and a IOB pin. > Then I call them cRD, cWR, sRD and sWR (c=clock, s=signal) > and use c or s version where appropriate. > > And yes, I haven't tested anything on a real hardware yet. Your FPGA has a clock. If it doesn't have a clock, it needs a clock. Either these signals are not synchronous to the FPGA clock or they aren't. If the signals are asynchronous, make the FPGA clock much faster than the CPU clock (this seems to be the case) and put the CPU control signals through synchronizers. Then sample those signals as synchronous using standard logic design practices. If the signals are synchronous, then you don't need to treat them as a clock - you can sample them with the FPGA clock. The fact that ISE will synthesize and build the design does not imply the design will work. Using control signals as clocks is nearly always a bad idea - in fact, I can't think of a time when it isn't. I'm going to have to asset again that you don't want to do what you're doing. There is a better way. Synchronous design principles do indeed work. Good luck! - NathanArticle: 135828
On Oct 17, 1:02=A0am, Nathan Bialke <nat...@bialke.com> wrote:
> > How else can I make a bi-dir data bus?
> > The only signals I can monitor are CS=3D0, RD=3D0 and
> > correct address bus (CS and ABUS not shown in the above code).
>
> > I can get by the whole thing (ie. ISE doesn't complain) if I connect
> > a RD and WR to two pins, a GCK pin and a IOB pin.
> > Then I call them cRD, cWR, sRD and sWR (c=3Dclock, s=3Dsignal)
> > and use c or s version where appropriate.
>
> > And yes, I haven't tested anything on a real hardware yet.
>
> Your FPGA has a clock. If it doesn't have a clock, it needs a clock.
> Either these signals are not synchronous to the FPGA clock or they
> aren't. If the signals are asynchronous, make the FPGA clock much
> faster than the CPU clock (this seems to be the case) and put the CPU
> control signals through synchronizers. Then sample those signals as
> synchronous using standard logic design practices. If the signals are
> synchronous, then you don't need to treat them as a clock - you can
> sample them with the FPGA clock.
>
> The fact that ISE will synthesize and build the design does not imply
> the design will work. Using control signals as clocks is nearly always
> a bad idea - in fact, I can't think of a time when it isn't.
>
> I'm going to have to asset again that you don't want to do what you're
> doing. There is a better way. Synchronous design principles do indeed
> work.
>
> Good luck!
>
> - Nathan
I don't understand why it shouldn't work.
This is an example from the 'Language Templates':
if <reset>=3D'1' then
<output> <=3D '0';
elsif (<clock>'event and <clock>=3D'0') then
<output> <=3D <input>;
end if;
How is this different from my examples above?
The only thing is more conditions, which should not matter.
Example for Bi-dir I/O, unregistered:
-- Declare the <top_level_port> as a 8-bit inout port
<top_level_port> <=3D <input_signal> when <output_enable_signal> =3D '0'
else "ZZZZZZZZ";
<input_signal> <=3D <top_level_port>;
How does that differ?
Anyway, I'm off to bed.
Article: 135829I'm interested to hear from anyone who has experience implementing Linux on Microblaze. How "smooth" is it? What are the pitfalls? Limitations/issues? I am not talking about uClinux but rather the MMU version/s. I hear conflicting reports. Hard processor vendors bash the heck out of it and tell us that it is an absolute nightmare (gee, I wonder why?). Xilinx and the disti are telling us that all will be fine. Which is it? -MartinArticle: 135830
backhus wrote: > Have a nice simulation > Eilert Thanks. That was the trick. I'm now simulating away... Regards JanArticle: 135831
aleksa wrote: > -- slave CPU ready flag > > if WR='0' and <same other coditions..> then > READY <= '0'; -- write detected, signal slave CPU is busy > > elsif rising_edge(SLAVE_CPU_ACK) then > READY <= '1'; > end if; > > (I need this READY signal to be edge sensitive, > not level, since slave CPU is really slow.) > > > Another example is a bi-dir data bus (RD is also used as GCK, > elsewhere): > > DBUS <= DATAOUT when RD='0' else "ZZZZZZZZ"; > > ISE gives warning (again, it works on Spartan 3): So are you saying this works on some targets, but not others, and it works on small examples, but not larger ones ? You can check the code is ok, by splitting the offending signal to two pins, and then RST use of the Clock is removed. If the tools (or silicon) still refuse to co-operate fully, you can always join two pins :) -jgArticle: 135832
You are correct that Altera does not provide a tool that programs a HEX file directly into the UFM. You should instead create a POF, JAM, or JBC file using the Quartus II software. See the MAX II Handbook Chapter 9, =93Using User Flash Memory in MAX II Devices,=94 at http://www.altera.com/literature/hb/max2/max2_mii51010.pdf. The Quartus II help on the Programmer and the Convert Programming Files dialog box may also be helpful. From my quick read of the MAX II Handbook chapter 9, it looks like you want to update your .hex file (or specify a new one in the altufm megafunction) and then generate a new .pof by re-running the Quartus II assembler. This POF will have your whole design in it, including the new UFM contents. Regards, Vaughn Altera [v b e t z (at) altera.com]Article: 135833
> I don't understand why it shouldn't work. It can work if you're very careful and happen to be adept at asynchronous logic design. However, there are probably easier and more robust ways of doing what you want to do. FPGA clock lines are designed to drive the clock inputs of flip-flops. To drive the non- clock inputs of flip-flops, the signal must leave the global line. Depending on the part, leaving a clock line can add much more delay than you'd expect. The delay will also vary build-to-build unless you constrain it appropriately. Even more fun to deal with will be the skew between the "clock" version of the signal and the "signal" version of your signal. > This is an example from the 'Language Templates': > > =A0 =A0if <reset>=3D'1' then > =A0 =A0 =A0 <output> <=3D '0'; > =A0 =A0elsif (<clock>'event and <clock>=3D'0') then > =A0 =A0 =A0 <output> <=3D <input>; > =A0 =A0end if; > > How is this different from my examples above? > The only thing is more conditions, which should not matter. Strictly speaking, you are correct - I must admit I was confused by the description of having two clocks drive a variable (hence, I was thinking of a two-clock flip-flop, which doesn't exist in Xilinx FPGAs). However, that's not the issue here. I would suggest that even if you get your design to synthesize, you are going to have issues with asynchronously loading registers and status flags. Unless you are extraordinarily careful (in particular, by ensuring all asynchronous paths are properly constrained and that any asynchronous loads do not lead to race conditions down the line in the data path), your build will fail randomly depending on temperature, process, and voltage variations. Further, you will have issues porting this code to other FPGA architectures if necessary. I don't want to discourage you, but I'd feel bad if an FPGA new-comer lost interest in the device by following non-standard design principles and then getting bit by them. - NathanArticle: 135834
On 2008-10-17, Fred <fred__bloggs@lycos.com> wrote: > scrambled, when and how. They are also very fussy in only accepting > data with a correct checksum! I was trying to debug an ethernet interface five years ago or so. At that time I wasn't sure if I was sending the correct CRC or not. To make a long story short, I modified the Linux driver for my Ethernet card so that it ignored the bad CRC bit. In that way I managed to look at my packets even though I normally wouldn't. Not that it helped though, my CRC was still bad and I still needed to figure out the correct way to send the CRC :) But perhaps this can be of some help to you while debugging your solution. /AndreasArticle: 135835
On Thu, 16 Oct 2008 10:47:38 -0700 (PDT), Fred <fred__bloggs@lycos.com> wrote: >Very much appreciate your response - will try in the alternative news >group. Generally if it's been done in an FPGA it would have been done >by someone here and would have sourced some literature, other than the >IEEE documents. The difference with 100b-tx is that there have been very few driver chips for it and on the receive side you need significant signal processing and the bit rate at 125 MHz is quite high so almost no one interfaces to it at that level. It's much easier to use a PHY chip which includes all of these and gives you parallel data at 25 MHz. Where did you even get the driver chip? National had one and I got some on Ebay quite a while ago for a prototype but I don't even think they're available anymore. I'd suggest you use a PHY with MII. Regards, Muzaffer Kal ASIC/FPGA Design Services DSPIA INC. http://www.dspia.comArticle: 135836
On Oct 17, 6:01=A0am, Muzaffer Kal <k...@dspia.com> wrote: > On Thu, 16 Oct 2008 10:47:38 -0700 (PDT), Fred > > <fred__blo...@lycos.com> wrote: > >Very much appreciate your response - will try in the alternative news > >group. =A0Generally if it's been done in an FPGA it would have been done > >by someone here and would have sourced someliterature, other than the > >IEEE documents. > > The difference with 100b-tx is that there have been very few driver > chips for it and on the receive side you need significant signal > processing and the bit rate at 125 MHz is quite high so almost no one > interfaces to it at that level. It's much easier to use a PHY chip > which includes all of these and gives you parallel data at 25 MHz. > Where did you even get the driver chip? National had one and I got > some on Ebay quite a while ago for a prototype but I don't even think > they're available anymore. I'd suggest you use a PHY with MII. > Even the slowest of FPGAs can be clocked in excess of 200MHz. Spartan 3E for example. Not much of the device needs to be clocked at this speed either. The scrambling is also possible and have done similar for another project some years ago. The output MLT-3 is also feasible. For some reason the IEEE 802 docs don't mention MLT-3 either, I suspect it's in there under another description. I accept that the driver for the line and magnetics has to be snappy, but was trying to get away from buying a PHY when all the other things can be done in the FPGA. In essence it would be nice to have an example stream to start with, even just in waveform. The notes I read so far is that different scrambling is used for idle and I need to read up more about it. I do know I have an obvious source of data, ie a real ethernet adaptor but it's not the same as a waveform down on paper, explaining what is scrambled, when and how. They are also very fussy in only accepting data with a correct checksum! Many thanks for your thoughts.Article: 135837
Hi,
I'm designing a PCI master core that has to drive the PCI bus at a
clock frequency (33MHz) different from the system clock. For clock
domain crossing, I'm using the FIFO from http://www.asic-world.com/examples/verilog/asyn_fifo.html.
It works fine in simulation and Xilinx tools seem to work well when
you tell them that the PCI clock is directly available at an input pin
(therefore unrelated to the system clock). But when I generate that
clock with a DCM, the Xilinx tools relates the PCI clock to the system
clock and, when it comes to timing analysis, then takes into account
asynchronous paths inside the FIFO with disastrous results :
Timing constraint: TSsystem = PERIOD TIMEGRP "clkin" 20 ns HIGH 50%;
1344910 paths analyzed, 14347 endpoints analyzed, 1007 failing
endpoints
1007 timing errors detected. (1006 setup errors, 1 hold error)
Minimum period is 28.976ns.
--------------------------------------------------------------------------------
Slack: -4.488ns (requirement - (data path - clock
path skew + uncertainty))
Source: pcibrg0/reply_queue/Mram_Mem36.SLICEM_F (RAM)
Destination: cpu0/exec0/intu0/rMSR_IE (FF)
Requirement: 10.000ns
Data Path Delay: 14.488ns (Levels of Logic = 8)
Clock Path Skew: 0.000ns
Source Clock: pci_clk_OBUF rising at 30.000ns
Destination Clock: clkin_IBUFG rising at 40.000ns
Clock Uncertainty: 0.000ns
(Of course, this also screws up the place-and-route process which
detects a high timing score and gives up all timing optimizations...)
I tried to force the tools to treat the clocks as unrelated using the
following constraints :
NET "pci_clk" TNM_NET="pci_clk";
TIMESPEC "TSpci_async"=FROM "clkin" TO "pci_clk" TIG;
But for some reason this has made them ignore most timing constraints
of my design :
------------------------------------------------------------------------------------------------------
Constraint | Check | Worst Case |
Best Case | Timing | Timing
| | Slack |
Achievable | Errors | Score
------------------------------------------------------------------------------------------------------
TSsystem = PERIOD TIMEGRP "clkin" 20 ns H | SETUP |
0.261ns| 19.739ns| 0| 0
IGH 50% | HOLD |
0.897ns| | 0| 0
------------------------------------------------------------------------------------------------------
PATH "TSpci_async_path" TIG | N/A | N/
A| N/A| N/A| N/A
------------------------------------------------------------------------------------------------------
(I'm supposed to have as well a 30ns period constraint on the PCI
clock and a 10ns constraint on "sdram_clk")
Any idea ? Or some FIFO design that does not trigger that problem ?
I would hate to use Coregen FIFO's, as they would not integrate well
with the rest of the design (except if you can get rid of the GUI and
use Coregen just like you would instantiate a HDL module, using things
like generics for the configuration options and not some obscure GUI-
generated files) and would create problems with the gplcver and Icarus
simulators that we use.
You can browse through my code here :
https://dev.openpattern.org/browser/trunk/fpga/aemb
Thanks !
Sebastien
Article: 135838Hi, From the experience we have at OpenPattern, the code is good enough but we are having lots of problems with broken build scripts and outdated toolchains. We are preparing an OpenWRT-based distribution that should address those issues. We are using the uClinux version for now, but we plan developments with the MMU-enabled one as well. Stay tuned :) SebastienArticle: 135839
On Oct 17, 8:06=A0am, Sebastien Bourdeauducq <sebastien.bourdeaud...@gmail.com> wrote: > Hi, > > I'm designing a PCI master core that has to drive the PCI bus at a > clock frequency (33MHz) different from the system clock. For clock > domain crossing, I'm using the FIFO fromhttp://www.asic-world.com/example= s/verilog/asyn_fifo.html. > > It works fine in simulation and Xilinx tools seem to work well when > you tell them that the PCI clock is directly available at an input pin > (therefore unrelated to the system clock). But when I generate that > clock with a DCM, the Xilinx tools relates the PCI clock to the system > clock and, when it comes to timing analysis, then takes into account > asynchronous paths inside the FIFO with disastrous results : > > Timing constraint: TSsystem =3D PERIOD TIMEGRP "clkin" 20 ns HIGH 50%; > > =A01344910 paths analyzed, 14347 endpoints analyzed, 1007 failing > endpoints > =A01007 timing errors detected. (1006 setup errors, 1 hold error) > =A0Minimum period is =A028.976ns. > -------------------------------------------------------------------------= ------- > Slack: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-4.488ns (requirement - (data p= ath - clock > path skew + uncertainty)) > =A0 Source: =A0 =A0 =A0 =A0 =A0 =A0 =A0 pcibrg0/reply_queue/Mram_Mem36.SL= ICEM_F (RAM) > =A0 Destination: =A0 =A0 =A0 =A0 =A0cpu0/exec0/intu0/rMSR_IE (FF) > =A0 Requirement: =A0 =A0 =A0 =A0 =A010.000ns > =A0 Data Path Delay: =A0 =A0 =A014.488ns (Levels of Logic =3D 8) > =A0 Clock Path Skew: =A0 =A0 =A00.000ns > =A0 Source Clock: =A0 =A0 =A0 =A0 pci_clk_OBUF rising at 30.000ns > =A0 Destination Clock: =A0 =A0clkin_IBUFG rising at 40.000ns > =A0 Clock Uncertainty: =A0 =A00.000ns > > (Of course, this also screws up the place-and-route process which > detects a high timing score and gives up all timing optimizations...) > > I tried to force the tools to treat the clocks as unrelated using the > following constraints : > > NET "pci_clk" TNM_NET=3D"pci_clk"; > TIMESPEC "TSpci_async"=3DFROM "clkin" TO "pci_clk" TIG; > > But for some reason this has made them ignore most timing constraints > of my design : > > -------------------------------------------------------------------------= ----------------------------- > =A0 Constraint =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0| =A0Check =A0| Worst Case | > Best Case | Timing | =A0 Timing > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 | =A0 =A0Slack =A0 | > Achievable | Errors | =A0 =A0Score > -------------------------------------------------------------------------= ----------------------------- > =A0 TSsystem =3D PERIOD TIMEGRP "clkin" 20 ns H | SETUP =A0 | > 0.261ns| =A0 =A019.739ns| =A0 =A0 =A0 0| =A0 =A0 =A0 =A0 =A0 0 > =A0 IGH 50% =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | HOLD =A0 =A0| > 0.897ns| =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 0| =A0 =A0 =A0 =A0 =A0 0 > -------------------------------------------------------------------------= ----------------------------- > =A0 PATH "TSpci_async_path" TIG =A0 =A0 =A0 =A0 =A0 =A0 =A0 | N/A =A0 =A0= | =A0 =A0 =A0 =A0 N/ > A| =A0 =A0 =A0 =A0 N/A| =A0 =A0 N/A| =A0 =A0 =A0 =A0 N/A > -------------------------------------------------------------------------= ----------------------------- > > (I'm supposed to have as well a 30ns period constraint on the PCI > clock and a 10ns constraint on "sdram_clk") > > Any idea ? Or some FIFO design that does not trigger that problem ? > > I would hate to use Coregen FIFO's, as they would not integrate well > with the rest of the design (except if you can get rid of the GUI and > use Coregen just like you would instantiate a HDL module, using things > like generics for the configuration options and not some obscure GUI- > generated files) and would create problems with the gplcver and Icarus > simulators that we use. > > You can browse through my code here :https://dev.openpattern.org/browser/= trunk/fpga/aemb > > Thanks ! > Sebastien Hi Sebastien, I have exactly the same problems in my design and would like be interested to hear if anyone knows how to turn this automatic clock relation off. However, I use two work arounds for this problem: The first is to create a TIMEGRP for each clock net and then enter something like this in the ucf: FROM grp1 TO grp2 TIG; also (so that it works the other way too)... FROM grp2 TO grp1 TIG; This will fix all of the cross clock analysis, however, I believe that this will now cause you a problem if you have any paths between the clock domains that you do want to constrain (for example setting the max logic delay). The issue here is that TIG has the highest priority and will therefore override a FROM-TO constraint. The second option is therefore to find each point in your design where logic crosses the clock domains and set a TIG specifically on those nets. Cheers RobArticle: 135840
Sebastien Bourdeauducq wrote: > > Any idea ? Or some FIFO design that does not trigger that problem ? Depending on the device you use, but, have a look at the RAMB16s Blocks they typically already provide FIFO-functionality, so it might be a possible idea to instantiate those cells directly, though you might lose portability in case you consider switching to altera for some reason. Regards, LorenzArticle: 135841
Hi, My design uses Synchronous reset for all the Flip-Flops. When I Synthesis and see the "Technology view" schematics in Synplify_pro; some FFs are infered using FDR and some used FD primitives. FDR - Has Synchronous reset input. FD - Do not have Synchronous reset input, and the Reset is added in the "D" path of FD primitive. Why such differences? I have read in some places that Xilinx recommend Synchronous reset for high performance. What is this mean, if FD is used in some places and having Reset in "D" path of the Flip-flop. Please clarify. Thanks in advance, MuthuArticle: 135842
On 17 Oct, 05:56, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2008-10-17, Fred <fred__blo...@lycos.com> wrote: > > > scrambled, when and how. =A0They are also very fussy in only accepting > > data with a correct checksum! > > I was trying to debug an ethernet interface five years ago or so. At > that time I wasn't sure if I was sending the correct CRC or not. To > make a long story short, I modified the Linux driver for my Ethernet card > so that it ignored the bad CRC bit. In that way I managed to look at my > packets even though I normally wouldn't. > > Not that it helped though, my CRC was still bad and I still needed to > figure out the correct way to send the CRC :) But perhaps this can be of > some help to you while debugging your solution. > > /Andreas I have found some software Colasoft Packet Builder which nicely tells you what the checksum would be. I have already done this for 10Base-T and generate packets in the FPGA and drive a fast RS485 driver IC. However 100Base-TX is somewhat more complex, with it's scrambling and 4B/5B encoding. I'm not familiar with Linux and use Windows <ducks to avoid remarks> We can only be expert in so many things at once! I don't really want to throw in the towel and buy PHYs! Many thanks for your reply.Article: 135843
On 2008-10-16, M.Randelzhofer <techseller@gmx.de> wrote: > However using CPLD's can be fun, and a student can learn a lot about logic > optimisation (speed versus area). Since this is their first time using any sort of hardware description language, we believe that it is good to use small CPLDs instead of large FPGAs. While there are certainly some students who would benefit from FPGAs, most of our students are satisfied with the designs they can do in a CPLD. Giving a large FPGA to a person who is not used to logic design is just an invitation to start programming in VHDL instead of designing hardware in VHDL if you understand what I mean... > In general bitserial processing is the way to go in low ressource CPLD's. This is the approach I'm using in my approach. This approach can really make a huge difference... > An 8bit PIC or similar architecture is a nice student project. Most of our students do some small microcoded CPU as their project in this course. Typically at least two CPLDs are used. One CPLD for the microcode and one for the ALU plus some registers like an accumulator and a program counter. /AndreasArticle: 135844
> So are you saying this works on some targets, but not others, > and it works on small examples, but not larger ones ? Yes. Please test this on XC3S50 TQFP144 and then on XC2S50 TQFP144: ---------------------------------------- library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity test is Port ( DBUS : out STD_LOGIC; clock1 : in STD_LOGIC; clock2 : in STD_LOGIC; data1 : in STD_LOGIC; data2 : in STD_LOGIC; out1 : out STD_LOGIC; out2 : out STD_LOGIC); end test; architecture Behavioral of test is -- attribute buffer_type: string; -- attribute buffer_type of clock2: signal is "bufgp"; begin process (clock1, clock2) begin if falling_edge(clock2) then out2 <= data2; end if; if clock2='0' then out1 <= 'Z'; elsif falling_edge(clock1) then out1 <= data1; end if; end process; DBUS <= data1 when clock2='0' else 'Z'; end Behavioral; ---------------------------------------- That should show that it works on S3 but fails on S2. As for the "and it works on small examples, but not larger ones" remove the comment on attribute lines and it will work on S2 (but not on S3). I'm not at liberty to show the complete design, however. BUFGP is probably a bad idea, anyway. > You can check the code is ok, by splitting > the offending signal to two pins, and then RST use > of the Clock is removed. > > If the tools (or silicon) still refuse to co-operate fully, > you can always join two pins :) That is what I was doing from the start (see s and c version) but wanted to have only one pin with the SAME SIGNAL. Since I'm meeting too much resistance, two pins-same signal is the way to go..Article: 135845
On Oct 17, 6:08 am, Nathan Bialke <nathan.bia...@gmail.com> wrote: > > I don't understand why it shouldn't work. > > It can work if you're very careful and happen to be adept at > asynchronous logic design. However, there are probably easier and more > robust ways of doing what you want to do. FPGA clock lines are > designed to drive the clock inputs of flip-flops. To drive the non- > clock inputs of flip-flops, the signal must leave the global line. > Depending on the part, leaving a clock line can add much more delay > than you'd expect. The delay will also vary build-to-build unless you > constrain it appropriately. Even more fun to deal with will be the > skew between the "clock" version of the signal and the "signal" > version of your signal. And how much is the delay? About 5ns? That is nothing. Even if it is 20ns, I don't see why would that matter: the main CPU writes the command and it doesn't matter whether it will be detected by the slave in 500ps or 20ns, the write-flag will remain until cleared. (The pulse width of the RD/WR is over 70ns) All other timings can only be longer. Anyway, I will use two pins, GCK and IOB, because I don't like to see any warnings from ISE. > > This is an example from the 'Language Templates': > > > if <reset>='1' then > > <output> <= '0'; > > elsif (<clock>'event and <clock>='0') then > > <output> <= <input>; > > end if; > > > How is this different from my examples above? > > The only thing is more conditions, which should not matter. > > Strictly speaking, you are correct - I must admit I was confused by > the description of having two clocks drive a variable (hence, I was > thinking of a two-clock flip-flop, which doesn't exist in Xilinx > FPGAs). However, that's not the issue here. I would suggest that even > if you get your design to synthesize, you are going to have issues > with asynchronously loading registers and status flags. Unless you are > extraordinarily careful (in particular, by ensuring all asynchronous > paths are properly constrained and that any asynchronous loads do not > lead to race conditions down the line in the data path), your build > will fail randomly depending on temperature, process, and voltage > variations. Further, you will have issues porting this code to other > FPGA architectures if necessary. > > I don't want to discourage you, but I'd feel bad if an FPGA new-comer > lost interest in the device by following non-standard design > principles and then getting bit by them. > > - Nathan If I use two pins, there is no problem synthesizing it. And why is it a "non-standard design" if it is copied from the templates? If signal A (from IOB) is connected to RESET, and signal B to CLOCK, I don't see why it would matter if signal A (from GCK) is also connected to a CLOCK of some other flip-flop that has nothing to do with the first flip-flop. Since I AM a FPGA new-comer, I don't really understand all the things you've said.. but, being stubborn as a mule, I will either succede or hit the brick wall. (then I'll come back, crying)Article: 135846
Hi, > I have exactly the same problems in my design and would like be > interested to hear if anyone knows how to turn this automatic clock > relation off. However, I use two work arounds for this problem: > > The first is to create a TIMEGRP for each clock net and then enter > something like this in the ucf: Could you be more precise about the way you created the TIMEGRP ? I did it this way : NET "clkin" TNM_NET="clkin_tnm"; NET "pci_clk" TNM_NET="pci_tnm"; TIMEGRP "clkin_grp" = "clkin_tnm"; TIMEGRP "pci_grp" = "pci_tnm"; TIMESPEC "TSpci_async1"=FROM "clkin_grp" TO "pci_grp" TIG; TIMESPEC "TSpci_async2"=FROM "pci_grp" TO "clkin_grp" TIG; and I have exactly the same result as when not using groups : ISE ignores most of my timing constraints. Fortunately, I don't have paths between the clock domains that I do want to constraint, everything is done in the FIFOs. So ignoring all relationships between the clocks is fine. Thanks, SebastienArticle: 135847
On 17 oct, 10:46, Lorenz Kolb <lorenz.k...@uni-ulm.de> wrote: > Depending on the device you use, but, have a look at the RAMB16s Blocks > they typically already provide FIFO-functionality, so it might be a > possible idea to instantiate those cells directly, though you might lose > portability in case you consider switching to altera for some reason. I'm using Spartan 3E, which, according to doc/usenglish/books/docs/ spartan3e_hdl/spartan3e_hdl.pdf in ISE documentation, does not provide hardwired FIFOs.Article: 135848
Hi Vaughn, vaughnbetz@gmail.com wrote in news:b19ac426-a23b-407b-a377- 39956f9fe5dc@u28g2000hsc.googlegroups.com: > You are correct that Altera does not provide a tool that programs a > HEX file directly into the UFM. You should instead create a POF, JAM, > or JBC file using the Quartus II software. See the MAX II Handbook Thanks, yes I was aware of how to do this, and I have done this for my working prototype. ... > II assembler. This POF will have your whole design in it, including > the new UFM contents. That is a problem, I do not want to ship the design part of the POF to end users. I cannot see a way in Quartus II v8 to make a POF file that does not include the CFM. I want to give end users a convenient means of changing parameters stored in UFM, and using Quartus II to make a POF file from a hex file is not convenient. A command line utility that made a JAM file from a hex file would be real convenient. I understand that, basically, there is no convenient simple way to take a hex file and load it into UFM via the JTAG port. In view of the apparent shortcoming in UFM endurance (guaranteed maximum 100 cycles, no guaranteed minimum), UFM seems to be not practical for storage of manufacturing data / parameters in the way that I intended and I will change the design to use an external EEPROM for parameter storage (endurance of the order of a million cycles, though a guaranteed endurance of a hundred cycles would be adequate for my application). Thanks for your help. OwenArticle: 135849
Dear all,
I'm trying to map two 16bit wide buses into one 32 bit wide bus.
I can't get the syntax right though.
How do I connect the bits (15 downto 0) from bus16a to bus32 (15 downto
0) and bits (15 downto 0) from bus16b to bus32 (31 downto 16)?
My VHDL:
architecture Behavioral of bus_test is
component bus16 is
port (
data16 : out std_logic_VECTOR(15 downto 0);
);
end component;
component bus32 is
port (
data32 : in std_logic_VECTOR(31 downto 0);
);
end component;
begin
bus16a_inst : bus16
port map ( );
bus16b_inst : bus16
port map ( );
bus32_inst : bus32
port map ( );
end;
Thank you in advance!
regards
Jan
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