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
"Antti.Lukats@googlemail.com" <antti.lukats@googlemail.com> wrote:
>On Aug 23, 8:59=A0pm, Frank Buss <f...@frank-buss.de> wrote:
>> Antti.Luk...@googlemail.com wrote:
>> > did you check the genode-FX?
>>
>> > they have full gui and graphics library support also, all free to use
>>
>> Thanks, the high-level part is interesting. But I have browsed the VHDL
>> files and it seems that they don't implement any graphics acceleration,
>> except fast screen clear, and it is a standard framebuffer concept, but
>> still very complete with the software graphics library. Drawbacks are, th=
>at
>> it is available as GPL or commercial, only and very Xilinx specific. My
>> system is BSD, which might be better for small commercial projects and
>> should work on FPGAs from other vendors, too.
>>
>> --
>> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys=
>tems.de
>
>yes, GPL is real bad thing, one latest example is OpenOCD project
>they can not distribute compiled binaries if those support FTDI
>drivers
>due to GPL restrictions.
Fortunately you can also use the free USB drivers for the FTDI chips.
Not much is lost.
>recompiling OpenOCD from sources for windows is sure possible
>but having precompiled version would make live much more easier
>well, GPL prevents that...
Indeed. That pissed me off as well.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142651On Aug 24, 8:04=A0pm, n...@puntnl.niks (Nico Coesel) wrote: > Frank Buss <f...@frank-buss.de> wrote: > >Antti.Luk...@googlemail.com wrote: > > >> did you check the genode-FX? > > >> they have full gui and graphics library support also, all free to use > > >Thanks, the high-level part is interesting. But I have browsed the VHDL > >files and it seems that they don't implement any graphics acceleration, > >except fast screen clear, and it is a standard framebuffer concept, but > >still very complete with the software graphics library. Drawbacks are, t= hat > >it is available as GPL or commercial, only and very Xilinx specific. My > >system is BSD, which might be better for small commercial projects and > >should work on FPGAs from other vendors, too. > > Did you even look into a Yamaha VG9938? This chip has acceleration for > copying and line draw. AFAIK it is available as HDL source. There is > also a VG9958 which is better & faster. These chips where used in MSX > home computers. > > -- > Failure does not prove something is impossible, failure simply > indicates you are not using the right tools... > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"If it doesn't fit, use a bigg= er hammer!" > -------------------------------------------------------------- MSX source is available (was) YES, so whatever is used there should be there too AnttiArticle: 142652
Nico Coesel wrote: > Did you even look into a Yamaha VG9938? This chip has acceleration for > copying and line draw. AFAIK it is available as HDL source. There is > also a VG9958 which is better & faster. These chips where used in MSX > home computers. I've found some datasheet for V9938. Why do you think it is worth to take a look at it? It looks like other graphics chips from this time, e.g. the MOS 6567 from the C64, but with some more features, like bitblitting and better sprites. Of course, my YaGraphCon has less features, but it is my first graphics controller, so the main goal was that it works at least :-) Maybe I'll enhance it with some microcode. Then it should be possible to implement text mode or sprites with different microcode instead of hardwired hardware and it would need less block RAM. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142653
On Aug 24, 8:37=A0pm, Frank Buss <f...@frank-buss.de> wrote: > Nico Coesel wrote: > > Did you even look into a Yamaha VG9938? This chip has acceleration for > > copying and line draw. AFAIK it is available as HDL source. There is > > also a VG9958 which is better & faster. These chips where used in MSX > > home computers. > > I've found some datasheet for V9938. Why do you think it is worth to take= a > look at it? It looks like other graphics chips from this time, e.g. the M= OS > 6567 from the C64, but with some more features, like bitblitting and bett= er > sprites. > > Of course, my YaGraphCon has less features, but it is my first graphics > controller, so the main goal was that it works at least :-) Maybe I'll > enhance it with some microcode. Then it should be possible to implement > text mode or sprites with different microcode instead of hardwired hardwa= re > and it would need less block RAM. > > -- > Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-sys= tems.de cheer up! great! dont get upset on replies, most of us have not made a grpachical controller with hardware accelerated features in 3 days! I havent. MOST of the readers havent. except YOU :) the double RAM requirement is kinda nasty of course its always too little of them, well Altera has more than X in low cost families, hum, but i have no cyclone3s :( AnttiArticle: 142654
Antti.Lukats@googlemail.com wrote: > cheer up! > great! > > dont get upset on replies, most of us have not made a grpachical > controller > with hardware accelerated features in 3 days! > > I havent. > MOST of the readers havent. > except YOU :) Thanks! I'm not getting upset. Maybe Nico has some good ideas he wants to show me with the V9938. Do you have a link to VHDL source code for it? > the double RAM requirement is kinda nasty of course > its always too little of them, well Altera has more than X in low cost > families, hum, but i have no cyclone3s :( Yes, this is the main drawback. But this was the reason why it was so easy to implement it: One exclusive read path for the graphics output, and one read/write path for the accelerator, all clocked with the pixel clock. The generic bit depth of the RAM is equal to the pixel depth. And I wrote already the VGA output some years ago in Verilog (but I rewrote it for the VHDL implementation, because the code was too messy). Bitblitting and line drawing is trivial with such a simple structure. I think when I'll add SRAM, which would need caching, bus arbitration etc., and maybe register configurable bit depth, it will be a lot more complex. Maybe I can avoid some of the complexity with a microcode architecture, or at least reduce the turnaround time for testing new code. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142655
Nico Coesel wrote: > Did you even look into a Yamaha VG9938? This chip has acceleration for > copying and line draw. AFAIK it is available as HDL source. Interesting. Where is this available. A quick googling didn't find anyting. -- Torfinn Ingolfsen, NorwayArticle: 142656
You must make sure to acknowledge the interrupt source (your custom core), and then the interrupt controller after each interrupt event (as well as the CPU-specific interrupt handling). Otherwise, the active interrupt source will immediately trigger another interrupt as soon as you exit your ISR. -Jason On Aug 20, 1:01=A0am, moon <moon3...@gmail.com> wrote: > Iam using XPS 8.2i.I have built a custom peripheral and attached it > to > MicroBlaze (v 5.0) via OPB bus.My peripheral generates the two > interrupts.These interrupts pins are input to the interrupt > controller > INTC (1.00 c). > Initially both interrupts are disabled.Then only high priority > interrupt is enabled. > What my objective is that when a high priority interrupt occurs:in > its > ISR it should disabled itself and enabled the other interrupt on > interrupt controller. > But actually what is happening that when high priority interrupt is > occurred it goes into its ISR and it doesnot disable itself.the other > interrupt is enabled and the microblaze is stuck in handling both the > interrupts. > Any help in this regard is welcomed!Article: 142657
Hi all, I've been working on a project using Quartus II (9.0 sp2) on a Stratix II part. This particular project requires that I set an attribute in the Assignment editor to prevent the tools from automatically promoting one of my signals to a global clock line. The entry in my QSF file looks something like this: set_instance_assignment -name AUTO_GLOBAL_CLOCK OFF -to "myEntity:myEntity_inst|mySignal" The great news is, the above statement works. The bad news is, I have to move the attribute out of the QSF file and into my VHDL file to make the file more portable. So, I read the manual to figure out how to use the altera_attribute command, I put it into my VHDL code, and the tool went right on ahead and ignored it. :-\ Below is a sample of how I declared this particular attribute in my code. Does anyone have any idea why the tool ignores my attribute when it's in my VHDL, but doesn't when it's in my QSF file? In case, you're wondering the signal that the tool wants to promote is connected to the clock input of a register. I'm certain some will recommend that I use this signal as an enable signal for the register. However, I'm doing some non-traditional designs on the FPGA and this is not an option. These designs work great as long as the attribute is in the QSF file ... just not when it's in the VHDL file. Thanks for any help you can provide, James EXAMPLE CODE: architecture myArch of myEntity is signal sig_a, sig_b : std_logic; signal mySignal : std_logic; attribute altera_attribute : string; attribute altera_attribute of mySignal : signal is "-name AUTO_GLOBAL_CLOCK OFF"; begin ... -- The mySignal signal is connected to the clock input of a register -- and the Altera tool REALLY wants to convert it to a global clock -- mySignal <= sig_a xor sig_b; ... end myArch;Article: 142658
Hi,
The following code is for address decode at different states. I
always
have the error message:
ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<1>>
Sources are:
Signal <comp1/state/Out2> is assigned to logic
Signal <RAM_out<1>> in Unit <vhdl_0> is assigned to GND
ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<0>>
Sources are:
Signal <comp1/state/Out3> is assigned to logic
Signal <RAM_out<0>> in Unit <vhdl_0> is assigned to GND
ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<2>>
Sources are:
Signal <comp1/state/Out1> is assigned to logic
Signal <RAM_in<2>> in Unit <vhdl_0> is assigned to GND
ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<1>>
Sources are:
Signal <comp1/state/Out0> is assigned to logic
Signal <RAM_in<1>> in Unit <vhdl_0> is assigned to GND
ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal
<RAM_in_sel<0>>
Sources are:
Signal <comp1/state/Out4> in Unit <FSM_0> is assigned to GND
Signal <RAM_in<0>> in Unit <vhdl_0> is assigned to GND
----------------
I cannot understand the reason. In fact, the code is just like a VHDL
textbook's. What's wrong with it? Thanks.
state_update: process(CLK, RESET)
begin
if RESET = '1' then
RAM_in_sel <= (others => '0');
RAM_out_sel <= (others => '0');
else
if CLK'event and CLK = '1' then
RAM_in_sel <= RAM_in;
RAM_out_sel <= RAM_out;
state <= next_state;
end if;
end if;
end process;
state_p: process(state)
begin
case state is
when init =>
RAM_in <= "000";
RAM_out <= "001";
next_state <= st0;
when st0 =>
RAM_in_selection <= "010";
RAM_out_selection <= "011";
next_state <= st1;
when st1 =>
RAM_in_selection <= "100";
RAM_out_selection <= "101";
next_state <= init;
when others =>
RAM_in_selection <= "000";
RAM_out_selection <= "001";
next_state <= init;
end case;
end process;
Article: 142659
Frank Buss <fb@frank-buss.de> wrote:
>Nico Coesel wrote:
>
>> Did you even look into a Yamaha VG9938? This chip has acceleration for
>> copying and line draw. AFAIK it is available as HDL source. There is
>> also a VG9958 which is better & faster. These chips where used in MSX
>> home computers.
>
>I've found some datasheet for V9938. Why do you think it is worth to take a
>look at it? It looks like other graphics chips from this time, e.g. the MOS
>6567 from the C64, but with some more features, like bitblitting and better
>sprites.
I programmed quite a lot with it. Besides the line drawing it has a
lot of nifty features like video overlay (a friend of mine used an
MSX-2 computer to put subtitles on his semi-pro videos), masking (and,
or, not / xor) and so on. Ofcourse it is a design from 1985 but a
modern FPGA can easely run such a videoprocessor at much higher
resoltions.
This pages seems to link to the VG9938 vhdl sources (VDP Video Display
Processor).
http://www.ohnaka.jp/wiki/wiki.cgi?page=%BB%F7%C8%F3VDP
This seems to be the main project page:
http://www.hat.hi-ho.ne.jp/tujikawa/esepld/
These guys seem to have managed to put an entire MSX2 computer inside
an FPGA.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 142660On Aug 24, 6:10=A0pm, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > hi Jim, > > humm.. what IP core have you spotted doing context switch? > I suppose there are some, NIOS-I used windowed register file > (what could already be considered as context switch), my own > ABM Risc uses ram-register context switch for subroutines > and interrupts/thread, sure there must be others.. can you recall > some? None that do everything I would.... ;) A couple of month ago, there was mention of one here that sounded like it would time-slice, but it is rare to see. IMO Asymmetric slice should fit well into a FPGA - you could allocate a fast/small block ram for the crucial interrupt/core tasks, and allow more elastic off-memory for the rest. This would allow nice Debug options, and also run-time-sanity-checks, where the time-slice would run a continual watchdog/self test function. I did find an Asian 89C2051 clone, that claimed time-shared core, but that is silicon, not a FPGA core. IIRCX Sparc also allows a split register frame, so you pass params in one half, and get a fresh 'other half' for local variables. That has call depth limits, and needs considerable SW support, but should give very compact and fast code. > as of 18 bit, yes and no, for block RAM only, yes the 18 bits is very > nice for 16 bit datapath, but for a SoC with external memory bus, a 18 b= it > core is nono You can get SRAM in x18 x24 widths, but you are right, the HW has to have used that, and mostly they do not. -jgArticle: 142661
On Aug 23, 8:32=A0pm, -jg <jim.granvi...@gmail.com> wrote: > On Aug 22, 4:58=A0pm, green <atgree...@gmail.com> wrote: > > > On Aug 16, 5:51=A0am, "Antti.Luk...@googlemail.com" > > > <antti.luk...@googlemail.com> wrote: > > > YES, there is no need to point to the "usual suspects" > > > unless there is a real feeling, i have missed something obvious. > > > I've been working on a new `Free Software' soft core, but backwards. > > The gcc/binutils/gdb/simulator ports are already in the upstream FSF > > repositories. =A0I also have a qemu port and uClinux has just started t= o > > boot on the simulator. > > Interesting - how fast is the simulator ? There are actually two simulators. The first is the one built into GDB, and it's a very basic instruction interpreter written in C. I don't know how to characterize the speed other than to say that the uClinux kernel boots up to a busybox prompt in just a few seconds. The second simulator is a port of qemu, which uses JIT compiler technology to translate moxie instructions into x86 instructions on the fly, and it's a fair bit faster for most applications. > > > It's a 32-bit load/store architecture. =A0Most instructions are 16-bits= , > > but it also has 48-bit instructions for dealing with 32-bit immediate > > values. =A0I think this is fair trade-off that should result in compact > > code. =A0The ISA was designed specifically to be an excellent target fo= r > > GCC, although it still need tweaking (I've blogged all the details). > > Be interesting to see how this pathway fits on =A0FPGA. I'll let you know once I get there! AG > > In FPGA cores, you'll find things like 18 bit opcodes, as that is the > width > of block ram. > > More recent FPGA cores also target the dual-port memory blocks that > most > new FPGA's now include, but few I've seen also context switch that > memory. > - ie given that the memory-block is often larger than any core > register set needs, > switching within that for fast interrupts, or even hard time-slicing > better uses HW > that is 'almost free' > > -jgArticle: 142662
Nico Coesel wrote: >Frank Buss <fb@frank-buss.de> wrote: >>Nico Coesel wrote: >> >>> Did you even look into a Yamaha VG9938? This chip has acceleration for >>> copying and line draw. AFAIK it is available as HDL source. There is >>> also a VG9958 which is better & faster. These chips where used in MSX >>> home computers. >> >>I've found some datasheet for V9938. Why do you think it is worth to take a >>look at it? It looks like other graphics chips from this time, e.g. the MOS >>6567 from the C64, but with some more features, like bitblitting and better >>sprites. > >I programmed quite a lot with it. Besides the line drawing it has a >lot of nifty features like video overlay (a friend of mine used an >MSX-2 computer to put subtitles on his semi-pro videos), masking (and, >or, not / xor) and so on. Ofcourse it is a design from 1985 but a >modern FPGA can easely run such a videoprocessor at much higher >resoltions. > >This pages seems to link to the VG9938 vhdl sources (VDP Video Display >Processor). >http://www.ohnaka.jp/wiki/wiki.cgi?page=%BB%F7%C8%F3VDP > >This seems to be the main project page: >http://www.hat.hi-ho.ne.jp/tujikawa/esepld/ > >These guys seem to have managed to put an entire MSX2 computer inside >an FPGA. People have also recreated the Amiga <http://home.hetnet.nl/~weeren001/> and Atari ST <http://www.experiment-s.de/de/atari-ste-in-a-chip/> in FPGAs. An accelerator that sat on a shared bus like WishBone or PLB with a dumb framebuffer could be useful too. The VGA/LCD controller is usually in the "most popular" list on OpenCores, so some people must be using it. Robert SwindellsArticle: 142663
Nico Coesel wrote: > These guys seem to have managed to put an entire MSX2 computer inside > an FPGA. This project saw a brief commercial release in Japan in 2006. <http://en.wikipedia.org/wiki/1chipMSX> The full source was released and has been updated/improved by dedicated hobbyists, and even ported to other platforms such as the TerASIC DE1 (EP2C20). I managed to port it to proprietary Cyclone-II based (EP2C35) hardware a few years ago as well. FWIW the problem (IMHO) with the commercial release was that the design just barely fit inside the EP1C12. That left very little room for improvements and almost no chance of ever utilising the USB connectors routed on the PCB. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142664
Robert Swindells wrote: > People have also recreated the Amiga <http://home.hetnet.nl/~weeren001/> > and Atari ST <http://www.experiment-s.de/de/atari-ste-in-a-chip/> in > FPGAs. I think you'd be hard-pressed to find an 8/16-bit computer that _hasn't_ been recreated in an FPGA! :) Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 142665
Hi! Probably this is a bug in XST. I also had quite a lot of problems with it when I had an entity with a signal called RAM in it. Instantiating this entity only once in the whole design worked fine, but using it several times made XST go crazy... Try some different names for the signals (perhaps without RAM in it) to see whether this could be the problem. Matthias fl schrieb: > Hi, > The following code is for address decode at different states. I > always > have the error message: > > > > ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<1>> > Sources are: > Signal <comp1/state/Out2> is assigned to logic > Signal <RAM_out<1>> in Unit <vhdl_0> is assigned to GND > > ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<0>> > Sources are: > Signal <comp1/state/Out3> is assigned to logic > Signal <RAM_out<0>> in Unit <vhdl_0> is assigned to GND > > ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<2>> > Sources are: > Signal <comp1/state/Out1> is assigned to logic > Signal <RAM_in<2>> in Unit <vhdl_0> is assigned to GND > > ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_in<1>> > Sources are: > Signal <comp1/state/Out0> is assigned to logic > Signal <RAM_in<1>> in Unit <vhdl_0> is assigned to GND > > ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal > <RAM_in_sel<0>> > Sources are: > Signal <comp1/state/Out4> in Unit <FSM_0> is assigned to GND > Signal <RAM_in<0>> in Unit <vhdl_0> is assigned to GND > > ---------------- > > > > > > I cannot understand the reason. In fact, the code is just like a VHDL > textbook's. What's wrong with it? Thanks. > > > > > state_update: process(CLK, RESET) > begin > if RESET = '1' then > RAM_in_sel <= (others => '0'); > RAM_out_sel <= (others => '0'); > else > if CLK'event and CLK = '1' then > RAM_in_sel <= RAM_in; > RAM_out_sel <= RAM_out; > state <= next_state; > end if; > end if; > end process; > > state_p: process(state) > begin > case state is > when init => > RAM_in <= "000"; > RAM_out <= "001"; > next_state <= st0; > when st0 => > RAM_in_selection <= "010"; > RAM_out_selection <= "011"; > next_state <= st1; > when st1 => > RAM_in_selection <= "100"; > RAM_out_selection <= "101"; > next_state <= init; > when others => > RAM_in_selection <= "000"; > RAM_out_selection <= "001"; > next_state <= init; > end case; > end process;Article: 142666
I see there are a couple of Xilinx people at the LLVM meeting coming up: http://llvm.org/devmtg/2009-10/ Is the interest just in a replacement/alternate toolchain for the embedded CPUs or is it something more interesting around retargetting intensive code to FPGAs? Given the momentum building behind LLVM and the work from Livermore and Darmstadt the later seems likely. --- cdsArticle: 142667
I am working on the EARP,xilinx using ISE9.1i02 and planahead9.2.7. I tried
to designed a hard marco in Virtex2p and follow the guide book of xilinx.
But i have problem in my hard marco when implement the PAR,the error is
below:
ERROR: Macro bm_base_prm is located incorrectly on a region boundary.
The external portion of the slice macro appears inside the region
boundary.
The following external nets connect to slice macro bm_base_prm but
illegally cross the region boundary.Nets crossing region boundaries must be
defined in the slice macro.
Net "dip_base_prm[0]"
Net "dip_base_prm[1]"
Net "dip_base_prm[2]"
Net "dip_base_prm[3]"
Net dip_base_prm is the line between the dymatic moudle and hadr marco.
It is very strangely that when I used xilinx's marco, it worked. But my
hard marco is not work when all other's configuration is the same.
can anyone help out of this problem.Thanks.
Article: 142668Hi, I am doing this course in embedded systems in which I've to do a project using FPGA devices. The project description says that by using diversified propagation delays within the implemented designs it is possible to generate frequencies that are much higher than the system clock frequency. The objective of the project is to propose and implement techniques for generating signals (either frequencies of individual pulses) which are below the clock period threshold. At the system level, the project consists in determining propagation delays using programming tools (ISE platform). At the experimental level, the estimated timing characteristics are to be verified for repeatability, stability and consistency. I'm completely new to this field and am not aware of the terminologies. Can anyone please help me with this. Thanks.Article: 142669
icefish711 <icefish711@163.com> schrieb: > I am working on the EARP,xilinx using ISE9.1i02 and planahead9.2.7. I tried > to designed a hard marco in Virtex2p and follow the guide book of xilinx. > But i have problem in my hard marco when implement the PAR,the error is > below: > > ERROR: Macro bm_base_prm is located incorrectly on a region boundary. > The external portion of the slice macro appears inside the region > boundary. > The following external nets connect to slice macro bm_base_prm but > illegally cross the region boundary.Nets crossing region boundaries must be > defined in the slice macro. > Net "dip_base_prm[0]" > Net "dip_base_prm[1]" > Net "dip_base_prm[2]" > Net "dip_base_prm[3]" > Net dip_base_prm is the line between the dymatic moudle and hadr marco. > It is very strangely that when I used xilinx's marco, it worked. But my > hard marco is not work when all other's configuration is the same. > > can anyone help out of this problem.Thanks. Can you post the relevant UCF section for the REGIONS and the LOC of your macros? best regards -- Fabian SchuhArticle: 142670
Pallavi <pallavi_mp@rediffmail.com> wrote: < I am doing this course in embedded systems in which I've to do a project < using FPGA devices. The project description says that by using diversified < propagation delays within the implemented designs it is possible to < generate frequencies that are much higher than the system clock frequency. I don't quite understand that part. < The objective of the project is to propose and implement techniques for < generating signals (either frequencies of individual pulses) which are < below the clock period threshold. That part I can understand. < At the system level, the project consists < in determining propagation delays using programming tools (ISE platform). < At the experimental level, the estimated timing characteristics are to be < verified for repeatability, stability and consistency. I'm completely new < to this field and am not aware of the terminologies. Can anyone please help < me with this. Thanks. Completely now to electronics hardware, digital electronics, or progrmmable logic. If you don't have some understanding of digital electronics, that is a very hard way to start. Also, it is much harder in an FPGA, where the routing is determined by the computer, than in wires and gates on a PC board. This reminds me of the stories of Cray using PC board traces to delay signals such that they would arrive at the desired time at the destination gate. Basically, if you take a signal, delay it by two different values, then feed the two into an XOR gate, you will get a pulse with a length depending on the difference in the delay. -- glenArticle: 142671
glen herrmannsfeldt wrote: > Basically, if you take a signal, delay it by two different values, > then feed the two into an XOR gate, you will get a pulse with > a length depending on the difference in the delay. But if you are out of luck, ISE synthesizes it all into one lookup element. This sounds like a strange project description. They have to learn things which are considered bad design in real world projects? If the FPGA vendor changes something in the chip process, which could be perfectly within the specification, your pulse generator might not work any more and if you are working for a company, you can explain your boss, why she has to dump all the 10,000 nice and shiny new devices. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 142672
On Mon, 24 Aug 2009 13:38:18 -0700 (PDT), fl <rxjwg98@gmail.com> wrote: >Hi, >The following code is for address decode at different states. I >always >have the error message: > > > >ERROR:Xst:528 - Multi-source in Unit <vhdl_0> on signal <RAM_out<1>> >Sources are: > Signal <comp1/state/Out2> is assigned to logic > Signal <RAM_out<1>> in Unit <vhdl_0> is assigned to GND How well did it work in simulation? Look at documentation for the simulator's "drivers" command; this may help you identify the unwanted signal source. - BrianArticle: 142673
Frank Buss <fb@frank-buss.de> wrote: < glen herrmannsfeldt wrote: <> Basically, if you take a signal, delay it by two different values, <> then feed the two into an XOR gate, you will get a pulse with <> a length depending on the difference in the delay. < But if you are out of luck, ISE synthesizes it all into one < lookup element. Yes, it likely has to be hand coded with the low level tools. (I remember them in the Xact days, I haven't looked recently.) < This sounds like a strange project description. They have to < learn things which are considered bad design in real < world projects? I think it is to learn and understand exactly why they are bad. Though as I said, in the past they were used in real designs. Maybe not anymore. (Seymour is dead.) < If the FPGA vendor changes something in the chip process, < which could be perfectly within the specification, your pulse < generator might not work any more and if you are working for < a company, you can explain your boss, why she has to dump all < the 10,000 nice and shiny new devices. There were some interesting designs that Peter Alfke used to come up with, but he knew which were and were not going to work. Among others, he has a divide by 2.5 counter. (I don't think it uses these tricks, but is interesting anyway.) They can be used for clocking on rising and falling edge, though. -- glenArticle: 142674
It's not clear what you are doing. Maybe post the entire code. If RAM_in and RAM_out are inputs then this assignment may cause a multi-source. Perhaps you meant RAM_in_selection or perhaps RAM_in_sel? > case state is > when init => > RAM_in <= "000"; > RAM_out <= "001"; > next_state <= st0; > when st0 => > RAM_in_selection <= "010"; > RAM_out_selection <= "011"; > next_state <= st1; Brad Smallridge AiVision.com
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