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
Hi all, Can some one confirm that MDM is working under EDK 9.2 with PowerPC and PLB bus? Best regards, Mariusz. -- mg.Article: 134051
Hi,
After no response in the xilinx forums, I thought I'd post my problem
here to see if anyone has any ideas.
I have an xtclsh script that I'm using to implement a Xilinx FPGA
design using ISE. I'm having a problem determining if a synthesis
error occurred:
#########################################
# Script 1:
project open build/xilinx/$target/$target.ise
#(set device properties)
#(add files)
#(set synthesis properties)
puts "Starting Synthesis..."
if {[catch {
set result [process run "Generate Programming File"]
} msg] } {
puts "$msg"
puts "*******************************"
puts "ERROR: Synthesis failed"
puts "*******************************"
project close
exit 1
}
puts $result
project close
#########################################
The above works fine, unless an error occurs during synthesis. Below I
have introduced a deliberate error in the source. In this case, the
exception handler doesn't trigger, and $result contains "true":
#########################################
Changed current working directory to the project directory:
"C:/project/build/xilinx/target"
Starting Synthesis...
Reading design: computex_demo.prj
=========================================================================
* HDL
Compilation *
=========================================================================
Compiling verilog file "../../rtl/pads.v" in library work
ERROR:HDLCompilers:26 - "../../rtl/pads.v" line 21 Could not find
verilog include file 'pads_h.v'
Analysis of file <"demo.prj"> failed.
-->
Total memory usage is 107676 kilobytes
Number of errors : 1 ( 0 filtered)
Number of warnings : 0 ( 0 filtered)
Number of infos : 0 ( 0 filtered)
Process "Synthesis" failed
INFO:TclTasksC:1850 - process run : Generate Programming File is done.
true
#########################################
Any idea why this doesn't trigger the exception handler?
-----------------------------------------------------------------
A workaround is to perform the synthesis and implementation steps
explicitly.. however this runs extremely slowly for me:
#########################################
# Script 2:
project open build/xilinx/$target/$target.ise
#(set device properties)
#(add files)
#(set synthesis properties)
puts "Starting Synthesis..."
if {[catch {
process run "Synthesize - XST"
process run "Implement Design"
process run "Generate Programming File"
} msg] } {
puts "$msg"
puts "*******************************"
puts "ERROR: Synthesis failed"
puts "*******************************"
project close
exit 1
}
project close
#########################################
If there have been no source modifications, the above should do
absolutely nothing. Indeed this is the case, however it still takes
about 100 seconds to complete (Synthesise:35s, Implement:30s, Generate:
35s). Why do these steps all take so long when there is nothing to do?
Any advice would be much appreciated!
Article: 134052Hi All I know that there are good google groups devoted to fpga and vhdl design but struggle to find anything about digital systems design. I actually look for a forum or a discussion group where people of different levels (professionals and beginners as well) help to learn how to design digital systems and would be grateful for advice. Thank you. :)Article: 134053
Vagant wrote: > I know that there are good google groups devoted to fpga and vhdl > design but struggle to find anything about digital systems design. I > actually look for a forum or a discussion group where people of > different levels (professionals and beginners as well) help to learn > how to design digital systems and would be grateful for advice. Thank > you. :) Depends on what you mean by "digital systems". For FPGAs, this group is nice. If you want to use microcontrollers, comp.arch.embedded maybe a good newsgroup. For designing some cirucits with low-level gates, like 7400, you can try sci.electronics.design. For DSP, comp.dsp is a good group. If you need all of them, the comp.arch.embedded newsgroup is good, too :-) -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 134054
I have an .fx Xchange assignment file with FPGA pin assignments (portnames,pin numbers, direction io type etc..) but not a top level design file. I want to auto generate the top level design file from the assignments, which the pin assignment editor lets me do. Now, when I import the .fx file into the pin assignment editor, all the ports are assigned but their directions are not, even though the directions are specified in the .fx file (input, output, bidirectional). My problem is that when I auto generate the top level file, the directions are screwed up for some of the ports. Does anyone know what to do? ThanksArticle: 134055
blakaxe@gmail.com wrote: > Does anyone know what to do? I would write my own vhdl entity code, and I would enter the pin numbers manually. into quartus. -- Mike TreselerArticle: 134056
On Jul 23, 8:53 am, Mike Treseler <mtrese...@gmail.com> wrote: > blak...@gmail.com wrote: > > Does anyone know what to do? > > I would write my own vhdl entity code, > and I would enter the pin numbers manually. > into quartus. > > -- Mike Treseler I haven't entered pin numbers manually in years. Too easy to make mistakes, especially with pin counts in the K range. I have one PERL script that parses a wirelist into a spreadsheet, and another that turns the spreadsheet into a constraint file. And Quartus supports Tcl scripts for pin number entry, that method works "just fine" too. G.Article: 134057
ghelbig wrote:
> I haven't entered pin numbers manually in years. Too easy to make
> mistakes, especially with pin counts in the K range.
> I have one PERL script that parses a wirelist into a spreadsheet, and
> another that turns the spreadsheet into a constraint file.
> And Quartus supports Tcl scripts for pin number entry, that method
> works "just fine" too.
That makes good sense for pin numbers.
But direction should be inferred from the code,
and IO type and timing is a separate problem.
-- Mike Treseler
Article: 134058Brian Drummond wrote: (snip) > And a practically identical rate on 60Hz NTSC. But since NTSC (for VCRs > anyway, I can't remember if the same is true of broadcast) ran at > 59.94Hz to reduce interference from 60 Hz mains, American versions of > the digital audio tape systems ran at 44.056 kHz. The 59.94Hz comes from the requirements on the color subcarrier frequency and the audio carrier offset. For a variety of reasons, the audio carrier couldn't be moved. I believe, though, that video recorders will sync to the sync rates of the input signal, so it would record at 60Hz. (Tradition was that black and white transmissions would be at 60Hz, I don't know how long that stayed true, though.) I believe that pro video recorders allow one to supply a signal to synchronize playback, but consumer quality ones would expect the receiving device to sync to their output. -- glenArticle: 134059
rickman wrote: (snip) > I don't remember for sure what the basis of 44100 Hz was, but I think > it has to do with being compatible with TV scan rates. It is > divisible by both 50 Hz and 60 Hz. That sounds familiar. > But then so is 48,000 Hz. 44100 > has as divisors, a pair each of 2, 3, 5 and 7. I'm not sure why this > is, but the sevens make it incompatible with most standard clock rates > for audio. There was also a requirement that Beethoven's ninth would fit on one CD. It might be that 48kHz was just a little too high. There might also be other requirements for conversion to a video signal other than vertical scan rate. (Such as horizontal scan rate.) As I remember it, the 48kHZ chosen for DAT was to make conversion from 44.1kHz harder to prevent digital copies of CDs. Consumer DAT decks could play 44.1kHz, but not record it. Pro decks, used to master CDs, could presumably also record at 44.1kHz. -- glenArticle: 134060
On Jul 22, 2:34 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > Hi, > > Then it should be a direct match for the FSL interface. > If MicroBlaze executes a 'put' instruction , it will not write until the > FSL_M_Full flag is '0' and when it write it will set the FSL_M Write high > for one clock cycle. > MicroBlaze have plenty of options for the FSL instructions, you can get a= ll > about them in the reference manual. > > G=F6ran > > "Ray D." <ray.delvecc...@gmail.com> wrote in message > > news:693f947e-929e-49f6-939d-d834e0048121@27g2000hsf.googlegroups.com... > On Jul 21, 2:36 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > > > > > Hi, > > > Depending a little on how your busy signals work, you might just hook u= p > > your module to the FSL interface on MicroBlaze. > > Your busy signal needs be high when it can't accept a new word even whe= n > > there is no attempt to write to the module. > > MicroBlaze will also just do one cycle write so your module needs to > > accept > > a new word in one clock cycle when busy is low. > > > Connect: > > din(7 downto 0) -> FSL0_M_Data(24 to 31) > > din_ready -> FSL0_M_Write > > busy -> FSL0_M_Full > > > You need to enable FSL Interfaces to MicroBlaze with the parameter > > C_FSL_LINKS (set it to 1) > > You can write to the fsl interface with the function putfslx, you can r= ead > > more about this function in the document "OS and Libraries Document > > Collection". > > > G=F6ran > > > "Ray D." <ray.delvecc...@gmail.com> wrote in message > > >news:276dce6d-c9ed-4937-95ea-e3c86ff3656a@d45g2000hsc.googlegroups.com..= . > > > > Hey all, > > > > I have a Xilinx Spartan-3E starter board, and I'm implementing a > > > MicroBlaze processor on the FPGA. I would also like to use the LCD > > > which is on board, and I have already developed a hardware module tha= t > > > takes care of initialization and printing to the LCD. The interface > > > is shown below: > > > > entity LCD_top is > > > Port ( > > > clk : in STD_LOGIC; > > > reset : in STD_LOGIC; > > > > din : in STD_LOGIC_VECTOR (7 downto 0); > > > din_ready : in STD_LOGIC; > > > busy : out STD_LOGIC; > > > > LCD_D : out STD_LOGIC_VECTOR (11 downto 8); > > > LCD_E : out STD_LOGIC; > > > LCD_RS : out STD_LOGIC; > > > LCD_RW : out STD_LOGIC > > > > ); > > > end LCD_top; > > > > I really would like to instantiate this module along with the > > > processor core. My question is this - how would I go about > > > interfacing this with the MicroBlaze processor internal to the FPGA? > > > What I would like to do is define a GPIO port on the processor to > > > connect to the din, din_ready and busy lines of the LCD module, but I > > > keep getting the following error: > > > > ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO > > > CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD > > > \system.mhs line 150 > > > - connection is not connected to an external port! > > > MPD subproperties IOB_STATE=3DBUF|REG or THREE_STATE=3DTRUE require > > > that the port > > > be connected directly to an external port. > > > > Is there any way to work around this? I realize I could just connect > > > the LCD to the GPIO directly and write software drivers, but I'm > > > trying to avoid that because I already have the hardware module in > > > place and working smoothly. It will also be nice to have this > > > separate module so that it does the work of printing to the LCD, and > > > the processor itself can stay busy with other more important jobs. > > > > Also, is there an easier way to add another hardware module without > > > manually editing the generated VHDL files for the core? I'm not sure > > > if you can do that within Platform Studio. > > > > Any advice would be much appreciated, thanks! > > > > Ray > > That is how the module works so I'll have to try some of these > options! The busy signal is set high the entire time data is being > written to the LCD. Originally I had a module "program.vhd" that > controlled the LCD module along with a keyboard module that we we had > in place for user input. Within program.vhd, I implement a state > machine and check if the busy signal is high before writing to the > LCD. If busy =3D 0, then I set din_ready high and set the 8-bits of > data. This is buffered within the LCD module and you only need to > hold din_ready for a single cycle to write to the LCD. The LCD is > connected over a 4-bit interface to the FPGA and this is taken care of > within the LCD module. When the writing operation begins busy is set > to '1' until complete. > > Ray OK - I'm new to using the EDK and am having trouble implementing this with the FSL bus. I have a few questions: 1) When I create a custom peripheral, it generates an HDL wrapper - Do I simply edit this wrapper by instantiating my LCD_top module as a component within the top level design? 2) Should I check the box "Generate template driver files to help you implement software interface", or will the provided functions to read and write to the FSL bus suffice? 3) Do you know of any good tutorials on how to implement a custom peripheral on the FSL bus? I've come across a few for adding peripherals to the other buses, but most that I have found do not follow through with how to edit the VHDL files and correctly add the peripheral to the system in Platform Studio (they simply tell you go to 'Create/Import Custom Peripheral'). Any help/input is appreciated, thanks! RayArticle: 134061
On Jul 23, 3:26 pm, "Ray D." <ray.delvecc...@gmail.com> wrote: > On Jul 22, 2:34 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > > > > > Hi, > > > Then it should be a direct match for the FSL interface. > > If MicroBlaze executes a 'put' instruction , it will not write until th= e > > FSL_M_Full flag is '0' and when it write it will set the FSL_M Write hi= gh > > for one clock cycle. > > MicroBlaze have plenty of options for the FSL instructions, you can get= all > > about them in the reference manual. > > > G=F6ran > > > "Ray D." <ray.delvecc...@gmail.com> wrote in message > > >news:693f947e-929e-49f6-939d-d834e0048121@27g2000hsf.googlegroups.com... > > On Jul 21, 2:36 am, "G=F6ran Bilski" <goran.bil...@xilinx.com> wrote: > > > > Hi, > > > > Depending a little on how your busy signals work, you might just hook= up > > > your module to the FSL interface on MicroBlaze. > > > Your busy signal needs be high when it can't accept a new word even w= hen > > > there is no attempt to write to the module. > > > MicroBlaze will also just do one cycle write so your module needs to > > > accept > > > a new word in one clock cycle when busy is low. > > > > Connect: > > > din(7 downto 0) -> FSL0_M_Data(24 to 31) > > > din_ready -> FSL0_M_Write > > > busy -> FSL0_M_Full > > > > You need to enable FSL Interfaces to MicroBlaze with the parameter > > > C_FSL_LINKS (set it to 1) > > > You can write to the fsl interface with the function putfslx, you can= read > > > more about this function in the document "OS and Libraries Document > > > Collection". > > > > G=F6ran > > > > "Ray D." <ray.delvecc...@gmail.com> wrote in message > > > >news:276dce6d-c9ed-4937-95ea-e3c86ff3656a@d45g2000hsc.googlegroups.com= ... > > > > > Hey all, > > > > > I have a Xilinx Spartan-3E starter board, and I'm implementing a > > > > MicroBlaze processor on the FPGA. I would also like to use the LCD > > > > which is on board, and I have already developed a hardware module t= hat > > > > takes care of initialization and printing to the LCD. The interfac= e > > > > is shown below: > > > > > entity LCD_top is > > > > Port ( > > > > clk : in STD_LOGIC; > > > > reset : in STD_LOGIC; > > > > > din : in STD_LOGIC_VECTOR (7 downto 0); > > > > din_ready : in STD_LOGIC; > > > > busy : out STD_LOGIC; > > > > > LCD_D : out STD_LOGIC_VECTOR (11 downto 8); > > > > LCD_E : out STD_LOGIC; > > > > LCD_RS : out STD_LOGIC; > > > > LCD_RW : out STD_LOGIC > > > > > ); > > > > end LCD_top; > > > > > I really would like to instantiate this module along with the > > > > processor core. My question is this - how would I go about > > > > interfacing this with the MicroBlaze processor internal to the FPGA= ? > > > > What I would like to do is define a GPIO port on the processor to > > > > connect to the din, din_ready and busy lines of the LCD module, but= I > > > > keep getting the following error: > > > > > ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO > > > > CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD > > > > \system.mhs line 150 > > > > - connection is not connected to an external port! > > > > MPD subproperties IOB_STATE=3DBUF|REG or THREE_STATE=3DTRUE requi= re > > > > that the port > > > > be connected directly to an external port. > > > > > Is there any way to work around this? I realize I could just conne= ct > > > > the LCD to the GPIO directly and write software drivers, but I'm > > > > trying to avoid that because I already have the hardware module in > > > > place and working smoothly. It will also be nice to have this > > > > separate module so that it does the work of printing to the LCD, an= d > > > > the processor itself can stay busy with other more important jobs. > > > > > Also, is there an easier way to add another hardware module without > > > > manually editing the generated VHDL files for the core? I'm not su= re > > > > if you can do that within Platform Studio. > > > > > Any advice would be much appreciated, thanks! > > > > > Ray > > > That is how the module works so I'll have to try some of these > > options! The busy signal is set high the entire time data is being > > written to the LCD. Originally I had a module "program.vhd" that > > controlled the LCD module along with a keyboard module that we we had > > in place for user input. Within program.vhd, I implement a state > > machine and check if the busy signal is high before writing to the > > LCD. If busy =3D 0, then I set din_ready high and set the 8-bits of > > data. This is buffered within the LCD module and you only need to > > hold din_ready for a single cycle to write to the LCD. The LCD is > > connected over a 4-bit interface to the FPGA and this is taken care of > > within the LCD module. When the writing operation begins busy is set > > to '1' until complete. > > > Ray > > OK - I'm new to using the EDK and am having trouble implementing this > with the FSL bus. I have a few questions: > > 1) When I create a custom peripheral, it generates an HDL wrapper - Do > I simply edit this wrapper by instantiating my LCD_top module as a > component within the top level design? > > 2) Should I check the box "Generate template driver files to help you > implement software interface", or will the provided functions to read > and write to the FSL bus suffice? > > 3) Do you know of any good tutorials on how to implement a custom > peripheral on the FSL bus? I've come across a few for adding > peripherals to the other buses, but most that I have found do not > follow through with how to edit the VHDL files and correctly add the > peripheral to the system in Platform Studio (they simply tell you go > to 'Create/Import Custom Peripheral'). > > Any help/input is appreciated, thanks! > > Ray Two more things - 1) the four output ports of the LCD module must be connected to the external FPGA pins in order to drive the LCD. What is the best way to go about doing this? Is this something that can be edited within Platform Studio or do I need to manually edit VHDL/UCF files? I'm assuming I will have to add the outputs to the interface shown below. 2) When I choose the master interface for the FSL bus, the ports are defined as follows: -- DO NOT EDIT BELOW THIS LINE --------------------- -- Bus protocol ports, do not add or delete. FSL_Clk : in std_logic; FSL_Rst : in std_logic; FSL_S_Clk : out std_logic; FSL_S_Read : out std_logic; FSL_S_Data : in std_logic_vector(0 to 31); FSL_S_Control : in std_logic; FSL_S_Exists : in std_logic; FSL_M_Clk : out std_logic; FSL_M_Write : out std_logic; FSL_M_Data : out std_logic_vector(0 to 31); FSL_M_Control : out std_logic; FSL_M_Full : in std_logic -- DO NOT EDIT ABOVE THIS LINE --------------------- You mention that my din(7 downto 0) port should be connected to the FSL_M_Data port, but the former is an input while the latter is an output. Am I missing something? I tried to define this as a slave interface, but that also yields an error when I try to generate the bitstream. Thanks.Article: 134062
Hi, I am instantiating single port distributed ram, and placing it using an RLOC and BEL constraint. (ISE 9.1.3, Spartan 3A 1800 DSP) The mapper is erroring out with the message below. The message appears to be saying that the BEL attribute attached to the ram cannot be "F", it must be "G". I can't find any evidence in the datasheet explaining why this distributed ram bit can't be placed in BEL site "F". Any ideas? I actually instantiate 9 16x1 distributed rams, and RLOC them in a vertical column, starting at X0Y0 and finishing at X0Y4 (x must be even to force slice M usage, slice L doesn't support disti-ram). Each bit is alternately placed into F,G,F,G etc. It appears the first 8 bits place correctly - there are no errors. Only the final bit (bitloop(8)) errors out. All the other slices have both BEL sites filled with ram, this last bit only fills one of the sites....Might that have something to do with it? The clk, we, and flop ce are the same for all 9 bits. Any ideas on how to get more info out of the tools as to why the mapper is throwing this error? I tried instantiating 10 bits of ram, and it passes through the tools no problem - why can't I RLOC a RAM to just 1 BEL inside a slice? Cheers Andrew Pack:679 - Unable to obey design constraints (MACRONAME=filter_bank/ generate_mf_bank[1].matched_filter/dalut/hset, RLOC=X0Y4) which require the combination of the following symbols into a single SLICEM component: FLOP symbol "filter_bank/generate_mf_bank[1].matched_filter/dalut/ bit_loop[8].yes_dout_flop.dout_flop" (Output Signal = filter_bank/ generate_mf_bank[1].matched_filter/pp<8>) RAM symbol "filter_bank/generate_mf_bank[1].matched_filter/dalut/ bit_loop[8].ram_bit" (Output Signal = filter_bank/ generate_mf_bank[1].matched_filter/dalut/dout_no_reg<8>) Function generator filter_bank/generate_mf_bank[1].matched_filter/ dalut/bit_loop[8].ram_bit has a site constraint other than "G". Please correct the design constraints accordingly.Article: 134063
The '16 Bit Microcontroller' at Opencores by Dr. Juergen Sauermann is also an impressive piece of work. rickman wrote: > On Jul 20, 8:21 am, Henri <h...@s.fi> wrote: >> On 19.7.2008 6:07, rickman wrote: >> >> >> >>> I may need to add a CPU to a design I am doing. I had rolled my own >>> core once with a 16 bit data path and it worked out fairly well. But >>> it was 600 LUT/FFs and I would like to use something smaller if >>> possible. The target is a Lattice XP3 with about 3100 LUT/FFs and >>> about 2000 are currently used. I believe that once I add the CPU >>> core, I can take out a lot of the logic since it runs so slowly. The >>> fastest parallel data rate is 8 kHz with some at 1 kHz and the rest at >>> 100 Hz. I probably would have used a CPU to start with instead of the >>> FPGA, but there was a possible need to handle higher speed signals >>> which seems to have gone away. >>> I recall that someone had started a thread about serial >>> implementations of processors that were supported by a C compiler. I >>> don't think any ever turned up. But the OP had some other >>> requirements that may have excluded a few very small designs. Are >>> there any CPU cores, serial or parallel, that are significantly >>> smaller than 600 LUT/FFs? The Lattice part has LUT memory even dual >>> port, so that is not a constraint, the LUTs can be used for >>> registers. >>> Rick >> Maybe something worth checking: >> >> http://www.zylin.com/zpu.htm >> >> From the above website: >> >> 1. The ZPU is now open source. See ZPU mailing list for more details. >> 2. BSD license for HDL implementations--no hiccups when using in >> proprietary commercial products. Under the open source royalty free >> license, there are no limits on what type of technology (FPGA, >> anti-fuse, or ASIC) in which the ZPU can be implemented. >> 3. GPL license for architecture, documentation and tools >> 4. Completely FPGA brand and type neutral implementation >> 5. 298 LUT @ 125 MHz after P&R with 16 bit datapath and 4kBytes BRAM >> 6. 442 LUT @ 95 MHz after P&R with 32 bit datapath and 32kBytes BRAM >> 7. Codesize 80% of ARM thumb >> 8. Configurable 16/32 bit datapath >> 9. GCC toolchain(GDB, newlib, libstdc++) >> 10. Debugging via simulator or GDB stubs >> 11. HDL simulation feedback to simulator for powerful profiling >> capabilities >> 12. Eclipse ZPU plug-in >> 13. eCos embedded operating system support. >> >> Henri > > I'm pretty impressed. Small, fast and with GCC support! > > RickArticle: 134064
On Jul 23, 5:26 pm, "Robert F. Jarnot" <Robert.F.Jar...@jpl.nasa.gov> wrote: > The '16 Bit Microcontroller' at Opencores by Dr. Juergen Sauermann is > also an impressive piece of work. Can you tell us what you find impressive about it? I took a look and it is listed as 800 slices which means it can be as big as 1600 LUTs. That is over three times the size of my CPU and an even larger ratio compared to the ZPU and others. Is it the fact that it has a C compiler and a simulator? RickArticle: 134065
What impresses me about this design is the approach -- determine what kind of architecture a 'clean' compiler would like to see, and implement the corresponding hardware and compiler. Throwing in an RTOS is a nice bonus too. I agree that your design is very impressive, both in resource usage and performance. I like some of the architectural details too, especially those borrowed from the transputer (looking back to the transputer for ideas is a good idea in my opinion). Having GCC support is a big plus too. What I do not have a feeling for is the relative performance of the two designs -- do you have any feeling for this? (Note to rickman: my initial reply was directly to you, not the newsgroup. Sorry. This reply is very similar to the one I sent you directly) rickman wrote: > On Jul 23, 5:26 pm, "Robert F. Jarnot" <Robert.F.Jar...@jpl.nasa.gov> > wrote: >> The '16 Bit Microcontroller' at Opencores by Dr. Juergen Sauermann is >> also an impressive piece of work. > > Can you tell us what you find impressive about it? I took a look and > it is listed as 800 slices which means it can be as big as 1600 LUTs. > That is over three times the size of my CPU and an even larger ratio > compared to the ZPU and others. > > Is it the fact that it has a C compiler and a simulator? > > RickArticle: 134066
On Jul 23, 6:57 pm, "Robert F. Jarnot" <Robert.F.Jar...@jpl.nasa.gov> wrote: > What impresses me about this design is the approach -- determine what > kind of architecture a 'clean' compiler would like to see, and implement > the corresponding hardware and compiler. Throwing in an RTOS is a nice > bonus too. > > I agree that your design is very impressive, both in resource usage and > performance. I like some of the architectural details too, especially > those borrowed from the transputer (looking back to the transputer for > ideas is a good idea in my opinion). Having GCC support is a big plus > too. What I do not have a feeling for is the relative performance of > the two designs -- do you have any feeling for this? > > (Note to rickman: my initial reply was directly to you, not the > newsgroup. Sorry. This reply is very similar to the one I sent you > directly) No problem. I was waiting for this one to appear so I could respond in public. I think there is some interest in the discussion. Yes, once I had a chance to look a bit more at the docs, I see the history and I also like the idea. I'm not sure why it is so large though. His design sounds simple with few registers and not even an internal stack if I understand correctly. The various Forth like CPUs all have one if not two internal stacks which in effect are local memories (in FPGA implementations). I expect (without looking at the design in detail) that this design suffers somewhat in speed in that things are done sequentially that can be done in parallel in other processors. But then those "other" processors are not built to run C. So I expect any fair comparison needs to take that into account. I can't say my design is impressive really. It is not complete in that there are no tools of any sort. I made a crude assembler but mostly hand coded in machine language. So I don't really have any idea of how fast it would run an application written in a high level language. I like to think that it would handle Forth pretty well, but I have not spent the time to really get that underway. I did see that the C16 (that is Dr. Juergen Sauermann's CPU name) is constructed somewhat like the 8080. That processor had a three machine cycle instruction timing and may have also used two input clocks for each machine cycle (this is really stretching my wayback machine). I remember this partly because I have an 8008 computer which was the predecessor to the 8080. It used the three machine cycles because it only had an 8 bit multiplexed bus. It used two cycles to output a 14 bit address (IIRC) and the third cycle was for the 8 bits of data. Every instruction was built of these three machine cycle memory ops (even if it was a register transfer). His machine seems to have emulated that and so uses up to 6 clock cycles for a basic instruction. I don't know much about the ZPU, but my CPU uses one clock cycle for any instruction other than program memory reads which require three cycles. You like the variable length literal instructions ala the Transputer? They are used to set up the immediate addresses for jumps and calls too. Unfortunately this makes for some trouble with defining addresses in the assembler. I never did get that to work correctly. Every time a byte was added or subtracted from the opcodes, it would move all of the other labels and you had to start over with the calculations. I think you could have situations that never converged. Otherwise I was pretty happy with my CPU. But I don't want to continue using it if there are better CPUs available. But it will be a couple of weeks before I can really spend any time on this. RickArticle: 134067
Andrew FPGA wrote: > Hi, > I am instantiating single port distributed ram, and placing it using > an RLOC and BEL constraint. (ISE 9.1.3, Spartan 3A 1800 DSP) The > mapper is erroring out with the message below. The message appears to > be saying that the BEL attribute attached to the ram cannot be "F", it > must be "G". I can't find any evidence in the datasheet explaining why > this distributed ram bit can't be placed in BEL site "F". Any ideas? > > I actually instantiate 9 16x1 distributed rams, and RLOC them in a > vertical column, starting at X0Y0 and finishing at X0Y4 (x must be > even to force slice M usage, slice L doesn't support disti-ram). Each > bit is alternately placed into F,G,F,G etc. It appears the first 8 > bits place correctly - there are no errors. Only the final bit > (bitloop(8)) errors out. All the other slices have both BEL sites > filled with ram, this last bit only fills one of the sites....Might > that have something to do with it? > > The clk, we, and flop ce are the same for all 9 bits. > > Any ideas on how to get more info out of the tools as to why the > mapper is throwing this error? > > I tried instantiating 10 bits of ram, and it passes through the tools > no problem - why can't I RLOC a RAM to just 1 BEL inside a slice? > > Cheers > Andrew > > > Pack:679 - Unable to obey design constraints (MACRONAME=filter_bank/ > generate_mf_bank[1].matched_filter/dalut/hset, RLOC=X0Y4) which > require the combination of the following symbols into a single SLICEM > component: > FLOP symbol "filter_bank/generate_mf_bank[1].matched_filter/dalut/ > bit_loop[8].yes_dout_flop.dout_flop" (Output Signal = filter_bank/ > generate_mf_bank[1].matched_filter/pp<8>) > RAM symbol "filter_bank/generate_mf_bank[1].matched_filter/dalut/ > bit_loop[8].ram_bit" (Output Signal = filter_bank/ > generate_mf_bank[1].matched_filter/dalut/dout_no_reg<8>) > Function generator filter_bank/generate_mf_bank[1].matched_filter/ > dalut/bit_loop[8].ram_bit has a site constraint other than "G". > Please correct the design constraints accordingly. I recall oddities like this from my more distant past. While it might be that it's one of the limited configurations supported by the silicon configuration (LUT in F, mem in G) try adding an RLOC compatible with the memory controls into that slice, BEL=G for that new element, and constrain the memory only to the slice, and not explicitly to the desired BEL. I've had odd experiences where constraining both elements to BELs will error the tool while constraining only one to a BEL but both to the slice creates no troubles. If you absolutely need the BEL=F orientation, you already know one workaround: 10 bit mems. To me it's less about finding out why the tool does something I don't like as it is about finding out how to get what I want from the tool. - John_HArticle: 134068
rickman wrote: > That is over three times the size of my CPU Which one is your CPU? Is it open source?Article: 134069
rickman wrote: > On Jul 23, 6:57 pm, "Robert F. Jarnot" <Robert.F.Jar...@jpl.nasa.gov> > wrote: >> What impresses me about this design is the approach -- determine what >> kind of architecture a 'clean' compiler would like to see, and implement >> the corresponding hardware and compiler. Throwing in an RTOS is a nice >> bonus too. >> >> I agree that your design is very impressive, both in resource usage and >> performance. I like some of the architectural details too, especially >> those borrowed from the transputer (looking back to the transputer for >> ideas is a good idea in my opinion). Having GCC support is a big plus >> too. What I do not have a feeling for is the relative performance of >> the two designs -- do you have any feeling for this? >> >> (Note to rickman: my initial reply was directly to you, not the >> newsgroup. Sorry. This reply is very similar to the one I sent you >> directly) > > No problem. I was waiting for this one to appear so I could respond > in public. I think there is some interest in the discussion. > > Yes, once I had a chance to look a bit more at the docs, I see the > history and I also like the idea. I'm not sure why it is so large > though. His design sounds simple with few registers and not even an > internal stack if I understand correctly. The various Forth like CPUs > all have one if not two internal stacks which in effect are local > memories (in FPGA implementations). I expect (without looking at the > design in detail) that this design suffers somewhat in speed in that > things are done sequentially that can be done in parallel in other > processors. But then those "other" processors are not built to run > C. So I expect any fair comparison needs to take that into account. > > I can't say my design is impressive really. It is not complete in > that there are no tools of any sort. I made a crude assembler but > mostly hand coded in machine language. So I don't really have any > idea of how fast it would run an application written in a high level > language. I like to think that it would handle Forth pretty well, but > I have not spent the time to really get that underway. > > I did see that the C16 (that is Dr. Juergen Sauermann's CPU name) is > constructed somewhat like the 8080. That processor had a three > machine cycle instruction timing and may have also used two input > clocks for each machine cycle (this is really stretching my wayback > machine). I remember this partly because I have an 8008 computer > which was the predecessor to the 8080. It used the three machine > cycles because it only had an 8 bit multiplexed bus. It used two > cycles to output a 14 bit address (IIRC) and the third cycle was for > the 8 bits of data. Every instruction was built of these three > machine cycle memory ops (even if it was a register transfer). > > His machine seems to have emulated that and so uses up to 6 clock > cycles for a basic instruction. I don't know much about the ZPU, but > my CPU uses one clock cycle for any instruction other than program > memory reads which require three cycles. > > You like the variable length literal instructions ala the Transputer? > They are used to set up the immediate addresses for jumps and calls > too. Unfortunately this makes for some trouble with defining > addresses in the assembler. I never did get that to work correctly. > Every time a byte was added or subtracted from the opcodes, it would > move all of the other labels and you had to start over with the > calculations. I think you could have situations that never > converged. > > Otherwise I was pretty happy with my CPU. But I don't want to > continue using it if there are better CPUs available. But it will be > a couple of weeks before I can really spend any time on this. > > Rick Yes, I like the idea of prefix instructions -- I am a believer in compact instruction sets, even if it makes the CPU slightly more complex. The transputer linker had the same issues you allude with yours -- the linker would sometimes have to make many 10's, or even a few hundred passes (for a large program) to make all of the variable length prefix instructions as short as possible. That is probably one of the reasons that the successor to the transputer from www.xmos.com looks much more like a modern register-based architecture with a lot of other clever transputer features retained or extended. Sauermann started with the 8080/Z80 only to come across the poor match to a C compiler. Since this was his starting point, I am not surprised that his final design shows some heritage from these designs. I would be very interested in knowing how your design fares with a C compiler (if someone smarter than me has the strength to do the port).Article: 134070
On Jul 23, 7:58 pm, Eric Smith <e...@brouhaha.com> wrote: > rickman wrote: > > That is over three times the size of my CPU > > Which one is your CPU? Is it open source? Mine was done some 6 or 7 years ago for a simple application and I never released it. I have called it "Bonus" for no special reason. If I decide to open source it I will try to come up with a better name. I don't know that it is anything special at this point. There are a *huge* number of CPUs available at opencores.org and other places. A quick count at opencores gives 93 processors, not counting the special purpose ones! Does the world really need another one??? The only problem is that most of them are not really very well documented. Very few of them even tell you how large they are in an FPGA or how fast they run. Heck, there are three just called, "Microprocessor" and one of those doesn't even have a page! We seem to have quantity, but quality only in a few. RickArticle: 134071
On Jul 23, 8:42 pm, "Robert F. Jarnot" <Robert.F.Jar...@jpl.nasa.gov> wrote: > rickman wrote: > > On Jul 23, 6:57 pm, "Robert F. Jarnot" <Robert.F.Jar...@jpl.nasa.gov> > > wrote: > >> What impresses me about this design is the approach -- determine what > >> kind of architecture a 'clean' compiler would like to see, and implement > >> the corresponding hardware and compiler. Throwing in an RTOS is a nice > >> bonus too. > > >> I agree that your design is very impressive, both in resource usage and > >> performance. I like some of the architectural details too, especially > >> those borrowed from the transputer (looking back to the transputer for > >> ideas is a good idea in my opinion). Having GCC support is a big plus > >> too. What I do not have a feeling for is the relative performance of > >> the two designs -- do you have any feeling for this? > > >> (Note to rickman: my initial reply was directly to you, not the > >> newsgroup. Sorry. This reply is very similar to the one I sent you > >> directly) > > > No problem. I was waiting for this one to appear so I could respond > > in public. I think there is some interest in the discussion. > > > Yes, once I had a chance to look a bit more at the docs, I see the > > history and I also like the idea. I'm not sure why it is so large > > though. His design sounds simple with few registers and not even an > > internal stack if I understand correctly. The various Forth like CPUs > > all have one if not two internal stacks which in effect are local > > memories (in FPGA implementations). I expect (without looking at the > > design in detail) that this design suffers somewhat in speed in that > > things are done sequentially that can be done in parallel in other > > processors. But then those "other" processors are not built to run > > C. So I expect any fair comparison needs to take that into account. > > > I can't say my design is impressive really. It is not complete in > > that there are no tools of any sort. I made a crude assembler but > > mostly hand coded in machine language. So I don't really have any > > idea of how fast it would run an application written in a high level > > language. I like to think that it would handle Forth pretty well, but > > I have not spent the time to really get that underway. > > > I did see that the C16 (that is Dr. Juergen Sauermann's CPU name) is > > constructed somewhat like the 8080. That processor had a three > > machine cycle instruction timing and may have also used two input > > clocks for each machine cycle (this is really stretching my wayback > > machine). I remember this partly because I have an 8008 computer > > which was the predecessor to the 8080. It used the three machine > > cycles because it only had an 8 bit multiplexed bus. It used two > > cycles to output a 14 bit address (IIRC) and the third cycle was for > > the 8 bits of data. Every instruction was built of these three > > machine cycle memory ops (even if it was a register transfer). > > > His machine seems to have emulated that and so uses up to 6 clock > > cycles for a basic instruction. I don't know much about the ZPU, but > > my CPU uses one clock cycle for any instruction other than program > > memory reads which require three cycles. > > > You like the variable length literal instructions ala the Transputer? > > They are used to set up the immediate addresses for jumps and calls > > too. Unfortunately this makes for some trouble with defining > > addresses in the assembler. I never did get that to work correctly. > > Every time a byte was added or subtracted from the opcodes, it would > > move all of the other labels and you had to start over with the > > calculations. I think you could have situations that never > > converged. > > > Otherwise I was pretty happy with my CPU. But I don't want to > > continue using it if there are better CPUs available. But it will be > > a couple of weeks before I can really spend any time on this. > > > Rick > > Yes, I like the idea of prefix instructions -- I am a believer in > compact instruction sets, even if it makes the CPU slightly more > complex. The transputer linker had the same issues you allude with > yours -- the linker would sometimes have to make many 10's, or even a > few hundred passes (for a large program) to make all of the variable > length prefix instructions as short as possible. That is probably one > of the reasons that the successor to the transputer fromwww.xmos.com > looks much more like a modern register-based architecture with a lot of > other clever transputer features retained or extended. Sauermann > started with the 8080/Z80 only to come across the poor match to a C > compiler. Since this was his starting point, I am not surprised that > his final design shows some heritage from these designs. I would be > very interested in knowing how your design fares with a C compiler (if > someone smarter than me has the strength to do the port). I want to say the ZPU is a stack oriented processor, two stacks in fact, like you would use for Forth; one is for data and the other for addresses, but I don't recall and I can't seem to find the docs on my hard drive. But ZPU has a C compiler, so you could compare this one to other, non-stack processors. RickArticle: 134072
Hi, You don't need the FSL_bus. You can directly take the MicroBlaze signals FSL0_M_Data, FSL0_M_Full, FSL0_M_Write and connect them to your module. If you want to do this in EDK, you will need to create a pcore for your module and manually connect these signal in XPS. You can also make these signal external to the EDK project and connect them in Project Navigator. It's depend on how your design look now. Göran "Ray D." <ray.delvecchio@gmail.com> wrote in message news:0b840fac-04c0-41a6-8ca1-99593fe48018@l64g2000hse.googlegroups.com... On Jul 23, 3:26 pm, "Ray D." <ray.delvecc...@gmail.com> wrote: > On Jul 22, 2:34 am, "Göran Bilski" <goran.bil...@xilinx.com> wrote: > > > > > Hi, > > > Then it should be a direct match for the FSL interface. > > If MicroBlaze executes a 'put' instruction , it will not write until the > > FSL_M_Full flag is '0' and when it write it will set the FSL_M Write > > high > > for one clock cycle. > > MicroBlaze have plenty of options for the FSL instructions, you can get > > all > > about them in the reference manual. > > > Göran > > > "Ray D." <ray.delvecc...@gmail.com> wrote in message > > >news:693f947e-929e-49f6-939d-d834e0048121@27g2000hsf.googlegroups.com... > > On Jul 21, 2:36 am, "Göran Bilski" <goran.bil...@xilinx.com> wrote: > > > > Hi, > > > > Depending a little on how your busy signals work, you might just hook > > > up > > > your module to the FSL interface on MicroBlaze. > > > Your busy signal needs be high when it can't accept a new word even > > > when > > > there is no attempt to write to the module. > > > MicroBlaze will also just do one cycle write so your module needs to > > > accept > > > a new word in one clock cycle when busy is low. > > > > Connect: > > > din(7 downto 0) -> FSL0_M_Data(24 to 31) > > > din_ready -> FSL0_M_Write > > > busy -> FSL0_M_Full > > > > You need to enable FSL Interfaces to MicroBlaze with the parameter > > > C_FSL_LINKS (set it to 1) > > > You can write to the fsl interface with the function putfslx, you can > > > read > > > more about this function in the document "OS and Libraries Document > > > Collection". > > > > Göran > > > > "Ray D." <ray.delvecc...@gmail.com> wrote in message > > > >news:276dce6d-c9ed-4937-95ea-e3c86ff3656a@d45g2000hsc.googlegroups.com... > > > > > Hey all, > > > > > I have a Xilinx Spartan-3E starter board, and I'm implementing a > > > > MicroBlaze processor on the FPGA. I would also like to use the LCD > > > > which is on board, and I have already developed a hardware module > > > > that > > > > takes care of initialization and printing to the LCD. The interface > > > > is shown below: > > > > > entity LCD_top is > > > > Port ( > > > > clk : in STD_LOGIC; > > > > reset : in STD_LOGIC; > > > > > din : in STD_LOGIC_VECTOR (7 downto 0); > > > > din_ready : in STD_LOGIC; > > > > busy : out STD_LOGIC; > > > > > LCD_D : out STD_LOGIC_VECTOR (11 downto 8); > > > > LCD_E : out STD_LOGIC; > > > > LCD_RS : out STD_LOGIC; > > > > LCD_RW : out STD_LOGIC > > > > > ); > > > > end LCD_top; > > > > > I really would like to instantiate this module along with the > > > > processor core. My question is this - how would I go about > > > > interfacing this with the MicroBlaze processor internal to the FPGA? > > > > What I would like to do is define a GPIO port on the processor to > > > > connect to the din, din_ready and busy lines of the LCD module, but > > > > I > > > > keep getting the following error: > > > > > ERROR:MDT - INST:LCD_data_status_10Bit PORT:GPIO_IO > > > > CONNECTOR:LCD_data_status_10Bit_GPIO_IO - C:\EDK_Test_LCD > > > > \system.mhs line 150 > > > > - connection is not connected to an external port! > > > > MPD subproperties IOB_STATE=BUF|REG or THREE_STATE=TRUE require > > > > that the port > > > > be connected directly to an external port. > > > > > Is there any way to work around this? I realize I could just > > > > connect > > > > the LCD to the GPIO directly and write software drivers, but I'm > > > > trying to avoid that because I already have the hardware module in > > > > place and working smoothly. It will also be nice to have this > > > > separate module so that it does the work of printing to the LCD, and > > > > the processor itself can stay busy with other more important jobs. > > > > > Also, is there an easier way to add another hardware module without > > > > manually editing the generated VHDL files for the core? I'm not > > > > sure > > > > if you can do that within Platform Studio. > > > > > Any advice would be much appreciated, thanks! > > > > > Ray > > > That is how the module works so I'll have to try some of these > > options! The busy signal is set high the entire time data is being > > written to the LCD. Originally I had a module "program.vhd" that > > controlled the LCD module along with a keyboard module that we we had > > in place for user input. Within program.vhd, I implement a state > > machine and check if the busy signal is high before writing to the > > LCD. If busy = 0, then I set din_ready high and set the 8-bits of > > data. This is buffered within the LCD module and you only need to > > hold din_ready for a single cycle to write to the LCD. The LCD is > > connected over a 4-bit interface to the FPGA and this is taken care of > > within the LCD module. When the writing operation begins busy is set > > to '1' until complete. > > > Ray > > OK - I'm new to using the EDK and am having trouble implementing this > with the FSL bus. I have a few questions: > > 1) When I create a custom peripheral, it generates an HDL wrapper - Do > I simply edit this wrapper by instantiating my LCD_top module as a > component within the top level design? > > 2) Should I check the box "Generate template driver files to help you > implement software interface", or will the provided functions to read > and write to the FSL bus suffice? > > 3) Do you know of any good tutorials on how to implement a custom > peripheral on the FSL bus? I've come across a few for adding > peripherals to the other buses, but most that I have found do not > follow through with how to edit the VHDL files and correctly add the > peripheral to the system in Platform Studio (they simply tell you go > to 'Create/Import Custom Peripheral'). > > Any help/input is appreciated, thanks! > > Ray Two more things - 1) the four output ports of the LCD module must be connected to the external FPGA pins in order to drive the LCD. What is the best way to go about doing this? Is this something that can be edited within Platform Studio or do I need to manually edit VHDL/UCF files? I'm assuming I will have to add the outputs to the interface shown below. 2) When I choose the master interface for the FSL bus, the ports are defined as follows: -- DO NOT EDIT BELOW THIS LINE --------------------- -- Bus protocol ports, do not add or delete. FSL_Clk : in std_logic; FSL_Rst : in std_logic; FSL_S_Clk : out std_logic; FSL_S_Read : out std_logic; FSL_S_Data : in std_logic_vector(0 to 31); FSL_S_Control : in std_logic; FSL_S_Exists : in std_logic; FSL_M_Clk : out std_logic; FSL_M_Write : out std_logic; FSL_M_Data : out std_logic_vector(0 to 31); FSL_M_Control : out std_logic; FSL_M_Full : in std_logic -- DO NOT EDIT ABOVE THIS LINE --------------------- You mention that my din(7 downto 0) port should be connected to the FSL_M_Data port, but the former is an input while the latter is an output. Am I missing something? I tried to define this as a slave interface, but that also yields an error when I try to generate the bitstream. Thanks.Article: 134073
Hi I have j-link jtag from iar system, its supplied by 5VDC from USB. Im wondernig if it would be possible to use it (with some modification) to program xinlix devices ? thx for help WJArticle: 134074
I developed a basic SD card controller in SPI mode. At first, i struggled for a while, trying to figure out why sometimes it worked and sometimes not. 1) The card connetor is "flying" for now (breadboard) and 2) i used a "one hand long" cable to connect it to the FPGA module. I guess the problem is about reflections and card sensitivity to slow rising and falling signal edges. When i 1) shortened the cable and, at the same time, 2) lowered the spi clock frequency (below 400Khz) it started working on every test. ** Is there any way i can rise the spi clock while keeping the sd connector "off board"? ** I also notice that (with consecutive single block writes) as the sector number i write to sequentially, increases, more time is required for the block operation to complete. ** Is it normal? ** Starting from sector 1, i've not reached the sector 1000. I had to increase a timeout reference. --
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