Hi John, Yes, It's very important to check to you don't have unloced pins since they can be placed anywhere and do anything. There is always a problem with the memcon since it drives 32 address signals and the external memory doesn't have 32 address lines. Currently you can't slice a signal in .mhs file but I have created a small utility core which will split a bus into two smaller busses and by using two of these cores, I can trim down to A(0:31) to A(10:29) which is what exists on the P160 board. I have attached the core and also a code snippet from the .mhs file on how to use it. This core will be in the coming EDK release but we have a couple of these utility core and therefore we have added a prefix in the names of util_ So the core will be called util_bus_split in EDK 6.1. This core is for the EDK3.2 release. Great work Göran .... BEGIN bus_split PARAMETER INSTANCE = bus_split_0 PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE_IN = 32 PARAMETER C_SPLIT = 30 PORT Sig = sram_addr_i PORT Out1 = sram_addr_ii END BEGIN bus_split PARAMETER INSTANCE = bus_split_1 PARAMETER HW_VER = 1.00.a PARAMETER C_SIZE_IN = 30 PARAMETER C_SPLIT = 10 PORT Sig = sram_addr_ii PORT Out2 = sram_addr END .... John Williams wrote: > Schunke Jan-Hendrik wrote: > > Hi John, > > > > The only way (I know) to check if you have locked all pins is a look at the place and route report (./implementation/*.par). There you will find something like: > > > > ... > > Device utilization summary: > > > > Number of External IOBs 87 out of 812 10% > > Number of LOCed External IOBs 87 out of 87 100% > > ... > > > > Maybe you can write a simple script to parse the file and check these lines ;-) > > Hey that's a good idea, I could just add it into the makefile to do a > quick check and report if there's a problem... > > also thanks for the emac ucf stuff, i'll give it a go. i haven't tried > actually using the emac yet, just the first step which is that uclinux > is still happy in a system that has an emac on the bus - got to do > things one step at a time :-) > > John > > > > > Jan > > > > > >>-----Ursprüngliche Nachricht----- > >>Von: John Williams [mailto:jwilliams@itee.uq.edu.au] > >>Gesendet: Dienstag, 26. August 2003 14:57 > >>An: microblaze-uclinux@itee.uq.edu.au > >>Betreff: Re: [microblaze-uclinux] ethernet + EMC > >> > >> > >>Hi Jan, > >> > >> > >>>The D0-D7 signals on the P160 are shared for FLASH/SRAM and LCD > >>>connector. > >> > >>The LCD signals are buffered by the cool runner. Did you > >>accidently reprogram the coolrunner and it pulls down the > >>lines now? There are also some signals that control the > >>coolrunner: PLD_LCD_RWN, PLD_LCD_EN ... I would check these, too. > >> > >>you are correct! i am bitten once again by the "random > >>allocation of unconstrained pins" behaviour of the synthesis > >>tools.... grrrr... but I should know better. :-) > >> > >>does anyone one know a synthesis switch so unconstrained pin > >>LOCs cause an error instead of silent potentially dangerous behaviour? > >> > >>I had declared the gpio to be 32 bit wide but only > >>constrained the lowest 24 bits - I was just lucky in earlier > >>mbvanilla targets, but this time the new io's of the MAC > >>caused these unconstrained gpio's to move, in this case onto > >>the CPLD write enable line... > >> > >> > >>>I have taken a quick look at your mhs and that seems to be ok. > >> > >>it should be - the ethernet stuff I lifted directly from a > >>reference design you sent me a while ago :) > >> > >>Thanks for your help - uclinux network access gets one step closer... > >> > >>John > >> > >> > >>>Jan > >>> > >>> > >>> > >>>>-----Ursprüngliche Nachricht----- > >>>>Von: John Williams [mailto:jwilliams@itee.uq.edu.au] > >>>>Gesendet: Dienstag, 26. August 2003 09:38 > >>>>An: microblaze-uclinux@itee.uq.edu.au > >>>>Betreff: [microblaze-uclinux] ethernet + EMC > >>>> > >>>> > >>>>Hi folks, > >>>> > >>>>Trying to bring up networking on uClinux, first step I've put a > >>>>xilinx ethernet MAC core in my project (surprisingly enough called > >>>>mbvanilla_net :). > >>>> > >>>>Anyway I've found that when I include the MAC core, all of > >> > >>a sudden > >> > >>>>my EMC peripheral (which drives the flash and SRAM) doesn't > >>>>work. The low > >>>>byte of all reads in the EMC address space returns > >> > >>0xFF...the high 3 > >> > >>>>bytes are fine... > >>>> > >>>>I can query the ethernet MAC device ID register, and the > >> > >>BRAM and DDR > >> > >>>>memory are unaffected. > >>>> > >>>>So, I can upload an image direct into DDR and execute it, no > >>>>problems, however my bootloading process of reading from > >> > >>flash and so > >> > >>>>on can't work - all reads from flash are corrupted by this > >> > >>0xFF byte. > >> > >>>>Has anybody had any experiences, positive or negative, re: > >> > >>using the > >> > >>>>EMC and EMAC in the same target? I've attached the mhs > >> > >>and ucf files > >> > >>>>for reference. > >>>> > >>>>Any ideas of where to look would be greatly appreciated. > >>>> > >>>>Thanks, > >>>> > >>>>John > >>>> > >>> > >>>___________________________ > >>>microblaze-uclinux mailing list microblaze-uclinux@itee.uq.edu.au > >>>Project Home Page : > >> > >>http://www.itee.uq.edu.au/> ~jwilliams/mblaze-uclinux > >> > >>>Mailing > >> > >>List Archive : > >> > > > > http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ > > > > > > ___________________________ > > microblaze-uclinux mailing list microblaze-uclinux@itee.uq.edu.au Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > > Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ > > > > > > > > ___________________________ > > microblaze-uclinux mailing list > > microblaze-uclinux@itee.uq.edu.au > > Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > > Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/ > > -- > Dr John Williams, Research Fellow, > Reconfigurable Computing, School of ITEE > University of Queensland, Brisbane, Australia > Ph : (07) 3365 8305 > > ___________________________ > microblaze-uclinux mailing list > microblaze-uclinux@itee.uq.edu.au > Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux > Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
Attachment:
bus_split_v1_00_a.zip
Description: Zip compressed data