http://neil.franklin.ch/Projects/VirtexTools/Logfile - things done and to do author Neil Franklin, last modification see last entry near bottom background this project grew out of my project to clone the DEC PDP-10 system in an FPGA http://neil.franklin.ch/Projects/PDP-10/ lots of logic/Virtex/JBits entries are relevant subsets of the stuff in there first new, this project only, only written here, stuff is on 2001.04.06 Fri 1981.11.xx my first use of a computer, Z80 microprocessor based, Pascal and Assembler http://neil.franklin.ch/Computers/index.html http://neil.franklin.ch/Projects/index.html mid to late 198x.xx.xx designed data path for an 32bit Forth CPU using 74LSxx(x) TTL logic failled at control circuits due to not knowing enough about logic design did not even know about finite state machines in those days later 198x.xx.xx read about PALs in magazines, MMI 16R8/20R8, AMD 22V10 plans to do an CPU in an PAL, but even MMI 64R32 was too small, too few FFs did not know bitslice technique in those days, nor idea of external registers was too taken in from the idea of a single chip CPU, microprocessor 1990.01.xx saw first time Xilinx chips in magazines, looked like a great thing but could not afford the $5000 development tools as just ex-student 1991.09.xx saw Algotronix CAL1024 PC/AT card, but had just got new non-PC (NeXT) computer so I went a different career in programming, Unix, sysadmining digital electronics, particularly processors, staid an hobby interest 2000.08.19 Sat D G Conroy announces PDP-8/X implemented in an XCS10 FPGA http://neil.franklin.ch/Usenet/alt.sys.pdp8/20000819_something_for_everyone_s_amusement my interest in doing an CPU myself with programmable logic rewoke 2000.08.26 Sat - 2000.09.08 Fri Autumn holiday, offline, did thinking on programmable logic recalling PAL details of AND arrays, fixed ORs, macrocells remember Xilinx called many times 5L2 PAL, sketched ideas how this could work failled to come up with solution for routing signals past an logic element had never heard of PIPs, dominating chip, with CLBs embedded 2000.09.09 Sat looked at boards used by J Gray for XR16 XS40-010E+ (XC4010E) http://www.xess.com/prod018.html also XSV (XCV50-800) http://www.xess.com/prod014.html start looking at CPLD and FPGA vendor data sheets 2000.09.09 Xilinx, 2000.09.13 Altera, 2000.09.27 Atmel, 2000.10.22 Cypress Lucent too complicated, Gatefield&Quicklogic no data sheets Actel&Lattice websites fail (A wants JavaScript&Flash, L tons of my data) 2000.09.20 Wed visit gEDA (GPL Electronic Design Automation) web site 2000.09.23 Sat subscribe to comp.arch.fpga 2000.10.05 Thu Discussion about open source tools, no back ends, secret bitstreams http://neil.franklin.ch/Usenet/comp.arch.fpga/20001002_Amplify_experience vendor tools only for WindowsNT/Solaris, ev also for HP-UX/AIX must use Win tools under Wine http://www.polybus.com/xilinx_on_linux.html mentioning of gEDA free VHDL and Verilog simulators and synthesisers but all are only down to EDIF or XNF, then vendor back end tools take over also story of Neocad, company that reversed engineered a Xilinx chip pointed out reverse engineering is explicitely protected in some countries 2000.10.17 Tue I ask about programming languages VHDL vs Verilog http://neil.franklin.ch/Usenet/comp.arch.fpga/20001017_VHDL_vs_Verilog from reading courseware on a web site I don't like either of them possibly try cnets or PamDC, both C++ based instantiation of FPGA elements 2000.10.30 Mon visited cnets web site 2000.11.01 Wed question about JBits, I visit JBits site, is pure Java tool also works on instantiation of FPGA elements, will it work on Linux? http://neil.franklin.ch/Usenet/comp.arch.fpga/20001101_JBits http://www.xilinx.com/products/software/jbits/index.htm 2000.11.12 Sun ask Xilinx if JBits will work on Linux, yes it does, is used, but no support so that decides tool (JBits) and chip family (Virtex/Spartan-II) Spartan-II are architecturally Virtex, same bit stream, same tools http://neil.franklin.ch/Usenet/comp.arch.fpga/20000829_Spartan_II_vs_Virtex 2000.11.29 Wed JBits 2.4 installed, read ReadMe, Virtex architecture guide, JBits tutorial 2000.12.19 Tue started re-read of Java programming language book, for using JBits Xilinx Mail announce of JBits 2.5 2000.12.23 Sat JBits 2.5 installed, further reading of release notes, JBits history 2000.12.25 Mon one can generate null bit file also by readback and running MakeNullBs in tools http://neil.franklin.ch/Usenet/comp.arch.fpga/20001223_Question_about_programming_xcv100 mainly this means any chip size restrictions on board selection have gone 2000.12.31 Sun read Xilinx XAPP138/139/151 on Virtex configuration architecture CLBs are 18x48bits, LUT FF and BRAMdata positions are known 2001.01.02 Tue further re-read of Java book syntax chapter and applications chapter repeat went through JBits tutorial, lessons 1 and 2 (started), doing exercises for this copies null300.bit and JBitsHelloWorld.java javac JBitsHelloWorld.java, does not find com.xilinx.JBits.Virtex.* wrong CLASSPATH ~neil/src/JBits2.4, not /usr/local/JBits2.5, set right, OK java JBitsHelloWorld -XCV300 null300.bit JBitsHelloWorld.bit can't find com/xilinx/demo/JBitsHelloWorld, killed "package" line in source 2001.01.03 Wed repeat JBits tutorial, lesson 2 (continued) and 3 and 4 discovered that it says that direct lines only run E-W, not N-S the S[01][FG][1-4] "PIP Muxes" also only have constants for this discovered that the "Single" class is actually deprecated in the class list 4 separate classes for different connection types 2001.01.04 Thu make graph of Virtex CLB routing PIPs layout, which ones exist http://neil.franklin.ch/Projects/PDP-10/Virtex-CLB-PIPs output muxes done, begin with input muxes 2001.01.07 Sun continued graph of Virtex CLB routing PIPs layout input muxes finished from single/direct/gclk, no hex lines rearranged output behind input, not below, in same diagram 2001.01.10 Wed continued graph of Virtex CLB routing PIPs layout out to single muxes, tidyed up direct feedback thoughts about single to single arrangement looked again at XC5200 docu picture, detailled routing on page 15 of 73 http://www.xilinx.com/partinfo/5200.pdf reread Virtex routing docu 2001.01.19 Fri Kolja Sulimma mail, offer to use their development board they are making also claims that TQFP chips are hand-solderable, so it seems to be true 2001.01.27 Sat - 2001.02.03 Sat was on holiday skiing, offline, but did a bit of planning work idea of making an CLB/LUTdata/BRAM/BRAMdata dump/modify bits2ASCII program based on XAPP151, with support for typical ROM/RAM data distribution patterns 2001.02.06 Tue Xilinx Answer to mail, is OUT_EAST6, suggest using JRoute2, not PIPs by hand 2001.02.10 Sat looked at JBits JRoute and JRoute2 docs for a second time not much intro, will need direct analysis of JavaDocs reference manual 2001.02.21 Wed looked at Virtex/JBits docs corrections: exchanges W and E in all input lines, redone SingleToSingle added Tristate buffers and lines, do not yet completely comprehend Tbufs may try an design entirely based on Muxes, as the PDP-6 seems to have been 2001.02.24 Sat first explorative JBits coding http://neil.franklin.ch/Projects/PDP-10/src/ derived from JBits Tutorial examples, compiles and runs BoardScope crashes X server, lack of memory, Java bloat, increase swap space found another JBits docu bug doc/BoardScope/BoardScope.html com.xilinx.XHWIF.XHWIFException: XHWIFWithEvents reference not created. Invalid system name: - - -> -simulator:xcv300 2001.02.25 Sun found another JBits docu bug doc/VirtexArchitecture/Slice_Internals.html D: Controlled by same mem cells as D -> as R also questions which inputs and output of RAM_32x1 and DUAL_MODE also questions which inputs control writing to LUTs also questions about Tbufs, 2nd Mail to jbits@xilinx.com reading Virtex docs, discovered V/H Longlines and reading JBits they have TBufs, but not run-time switchable ones 2001.03.14 Wed 2nd Mail answer came from Xilinx, RAM_32_X_1 BX 5th address, BY data out, SR en 2001.03.17 Sat Xilinx Mail announce of JBits 2.6, tried install, failled, program hangs sent them a mail reporting the problem 2001.03.18 Sun post asking about Virtex TBUFs, and replacement for them http://neil.franklin.ch/Usenet/comp.arch.fpga/20010319_TBUFs_in_Virtex_and_later_chips_going_out_of_fashion_what_instead seems they are going out, and that my MUXCY hack is the best way to do it 2001.03.25 Sun control logic showed even larger problem with JBits row/col being CLBs, not LEs thoughts about subclassing com.xilinx.JBits.Virtex.Bits to make new Fpga.set() convert LE x,y to row=y/2, col=x/2, slice=x%2, LUT=y%2?G:F and while doing so swap row/y,col/x to x,y but this seems to collide with Java language restrictions, no preprocessor no structs (must make objects, using them is more code than I save) come to the conclusion that I do not like Java as language switching to Expr.F_LUT made program slow, because parsing strings at run time and code bloat because properly needs error test (why not try{} used?) and also dependant on LUT F or G 2 different functions but hand generated bitpatterns and conversion was awkward so I made a class L (Lut) to set LUTs fast, easy and without test uses 4 constants for out=in LUTs and Java bitwise operators but L.xx syntax bloated, better define the I1 to I4 and L() in every class 2001.03.29 Thu Xilinx Mail announce of JBits 2.6.1, mentions 2.6 Linux install trouble 2001.04.04 Wed tried 2.6.1 install, failled also, same hang, try on Solaris tomorrow at work shows problem with closed source non-free software and license enforcement shit I have 2.5 install for sure, as tar.gz and on backups but I don't want to be dependant on such stuff for future upgrades and for new programmers (must get newest from Xilinx, as I can not copy) I really need to get open source and freeware tools start impulse for making this project 2001.04.05 Thu Solaris systems at work only have Java 1.1.x on them, upgrade to 1.2.2 that wants newer Solaris 2.6 patches that we do not have installed I will have to update our 1.5 year old recommended patch set no time for that at the moment (begin of new semester) looked at JRoute and JRoute2, use seems to be Fpga.route(src, sink) where src/sink is Pin(row, col, wire) with wire from ResourceDB but JRoute2 seems to have no Pin(), is this missing in the docs? 2001.04.06 Fri further studying JRoute and JRoute2, conclusion JRoute2 uses JRoute Pin class for generating routing of buses in loops I need for each line coordinates make an coordinate row and col array, run for () on Bit=0..DataBits-1 may want to change from Col and Row variables to single 2 element arrays general organisation may want to put System.out.print at end of blocks first attempt at method for managing Pin names, make symbolic names may be better at beginning of block, also Pin array while configuring despite various tricks I have not managed to get an optimal design through Java particularly random logic ends up with about 10 code lines per gate problem is that I really need something like an C functions and structs but without using Java objects, which requires separate source file and so loses access to my various global variables using an method call with many parameters loses struct/object advantage I want an optimally compact code that does not obfuscate logic same global variable problem prevents making of subroutines for sections this is just one case of me getting frustrated with Java being a B&D language I need an non-Java but also low level tool, will have to make one myself up to here this file was just the subset PDP-10 Logfile relevant to here from here on this project adds its own stuff, not to do with PDP-10 first plans for reverse engineering the the bitfile using JBits to set individual bits and XAPP151 to dump a CLB for analysis JBits was made to appease academics after killing bitfile-documented XC6200 becomes now troyan mechanism to discover the Virtex bitfile 2001.04.07 Sat go back to for () with Row/Col and fill arrays and single Pins, use them later conclusion that JRoute2 uses JRoute Pin class is wrong compiling shows that JRoute2 wants Pin objects from JBits.CoreTemplate 2001.04.20 Fri LUGS mailing list thread in which I let out my frustration at Java limitations bad at global variables, because "everything is an object" ideology non extensibility of precompiled binary classes, like JBits is one no preprocessor to get round these limits would actually like to have an C compiler that makes JVM .class files found a web site about other programming languages for JVM http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html one of these is a gcc back end, a patch set, highly experimental http://www.csee.uq.edu.au/~csmweb/uqbt.html#gcc-jvm I once tried to compile gcc, without patches, failled, this is not for me 2001.05.02 Wed first load into BoardScope notice how slow Java/Swing tools are to use also annoying features such as shows too little info per CLB also does not show CLB tags when in show data mode, makes them near useless also tagging is per CLB and not per slice of LUT/FF possibly to save bits as there seems to be only 12 (0x0000..0x0fff) would prefer an better display, showing actual LUT patterns, not tags have a program read bitfile and display LUT patterns, an chip viewer faster/better tool will require writing something myself in C that will require understanding the bitfile, reverse engineering it 2001.05.?? ??? (various times up to now, no exact record) legal situation, analysis reverse engineering: explicitely legal here, even the sacred copyright has to step beside when disassmbling for interoperatibility I am not disassembling Virtex (chips), but it does point to this being OK note that disassembling JBits is forbidden, as I am making competing lib so any java dissassembly is out, must be black box, documented process copyright: I am not copying their bits, and JBits license no restrictions this may change in future versions, check before any upgrade patent: I do not know of any patented techniques I may be reinventing is slightly a dark horse, but I doubt strongly JBits to be patented trademark: I am not pretending to be them, or it to be their product do not use the Virtex logo or font for libvirtex web site design contract / non disclosure agreement: I have never signed one trade secret: I was never told anything secret, none to hold I am only going on information they released, so nothing secret also Xilinx did not sue Neocad, rather stonewall, then cooperate, later buy expected reactions from Xilinx to this use of JBits deny all support for me on JBits, at the moment I may still need it BRAM/IOBs so publish earliest after using all features and getting/using hardware change license of newer versions to prohibit it, only give out new version this will prevent new JBits users from taking place so publish late to increase JBits users before and reduce chance of change this is once again the damage that tight-arsedness does to society decided on the name libvirtex for this project thinking about what programming language, C, perl, Lisp, ... will be C library, because that is also implementation language for others planning on implementation vt_bit(row, col, VT_, <0or1>); for lowest level vt_(row, col, slice, <0or1forForG>, ); for comfort #define vt_le_(le-row, le-col, ); for placing vt_tag(); and vt_le_tag(); at LE level, only 3 bits, enough for mapping struct vt_gate { struct vt_pin[4] in; struct vt_pin out; } for routing support Virtex (like JBits), Spartan-II (binary compatible) conditional -Drisk_broken_chip Virtex-E and -EM, seem just more BRAMs/DLLs 2001.05.12 Sat discussion of Alteras Linux port of their tools and Xilinx port possibilities http://neil.franklin.ch/Usenet/comp.arch.fpga/20010510_Finally_an_FPGA_tool_chain_for_Linux_Altera_Quartus_II too late for my project, I will stay with existing path, also Xilinx better 2001.05.20 Sun further work getting into Virtex, look at programming BRAMs nothing in Intro or Tutorial or VAG, only JavaDocs reference manual to go by http://neil.franklin.ch/Projects/PDP-10/Virtex-BRAM-PIPs looks like pure PIP setting, JRoute will do that automatically 2001.05.23 Wed no tagging CLBs as not used for debugging anyway, also too little granularity need better system for showing what is where, show LUT patterns 2001.05.25 Fri - 2001.05.27 Sun was at a Linux User Group camp for the weekend, offline, no programming showing my project to others for the first time noticed on BurchED website he is now selling modified batch 3 models ex 24MHz osc of Spartan2+ and CPU-IO Plug-On are now 1..100MHz programmable also first mentioning of plans to perhaps do an reverse engineering and make an libvirtex to an colleague 2001.06.04 Mon yet another discussion about configuration bitstreams being secret http://neil.franklin.ch/Usenet/comp.arch.fpga/20010604_Xilinx_Configuration_Bitstream got me into thinking about libvirtex again, decided that I am going to do it and that I should start now collecting ideas/thoughts, to not lose/waste them 2001.06.07 Thu mentioned libvirtex to another colleague, as definite project, am now commited 2001.06.10 Sun while working on PDP-10 once again sidetracked into musing on libvirtex need to write down status so far to get it it off my system, to concentrate created libvirtex project directory and started logfile http://neil.franklin.ch/Projects/libvirtex/Logfile 2001.06.12 Tue printed out XAPP151 for taking on holiday, to study details and write dump tool or better even an graphical rendering of the LUTs, with bit pattern visible first concrete ideas how such an display should look 2001.06.13 Wed planning vt_bit() -> vt_clb(), vt_bram(), vt_iob(), vt_dll(), also vt_g*() or even better no vt_ as libvirtex will usually be used with no/few others dito constants such as F, G, I1, I2, I3, I4, F1..4, G1..4, N, E, S, W realised that using XAP151 will also require XAPP138 and Virtex data sheet revisited previously non-successfull web sites Vantis/Lattice still wants account and questions, Actel still broken Quicklogic now has a decent data book, but all devices in one, 11MByte a totally different system, neither LUTs nor 2:1-Muxes Gatefield site totally broken, no page 2001.06.14 Thu printed out XAPP138 and architecture part of Virtex data sheet, for holiday 2001.06.15 Fri Xilinx Mail announce of JBits 2.7, mentions Linux and NT install troubles 2001.06.16 Sat PDP-10 bug due to missing an F->G edit when moving an LUT this F/G different source (as opposed to Row variable) is annoying need better methodology, along line of RTPCore LE/LC granularity libvirtex comfort functions will offer use of 0/1 var for selecting LUTs 2001.06.20 Wed musing on chip display better than BoardScope, in true 2x3 CLB shape even 4x4 pixels for LUT disp, only 8x12 per CLB, X2S200 42*9x28*13=378x364 so 2x2 pixel per bit for LUTs are possible, and below 8x4 for FF state allows user to see used space (LUT!=0) and different units (diff LUTs) is better than the tag() from JBits, with separate viewer and needs code use details in XAPP151 to implement this, also BRAMs (3pit/pixel), IOs for detailed view use an click-active pop up, remove on un-click or move also possibly drag selected CLBs to an "dock" for constant display commands via pup up menues or hot keys, no actual GUI further addition edit FPGA content in this display, FPGA editor, routing? 2001.06.23 Sat - 2001.07.07 Sat was on summer holiday, offline, but did some planning and designing read XAPP151, bitstream just constant length header, with few variable fields then 3 data blocks for GCLK/CLB/BRAMctrl/IO, BRAMdata.left, BRAMdata.right between and after them also an fixed size "header" also at end of column and after all colums dummy date for pipe flushes actually all headers are flexible commands, but Xilinx uses standard set making an CLB dumper or an viewer should be no problem with this knowledge problem may be the 8 columns of GCLK PIPs, does JBits allow setting these Virtex-E and -EM is "mainly" just more BRAMs according to XAPP151 documented bits are LUT F0..15, G0..15, XQ, YQ, all at top slice 1 left, slice 0 right, "butterfly" arrangement, LUTS 0..15 inside-out BRAMdata ist top and bottom 32 rows of 4*18=72 row block for usage with different widths see XAPP130 chip display tool, make image with true CLB format 4x6, 1/2/3/4 pixel/element of these top 4x4 LUT bit 0123/4567/89AB/CDEF, beneath it 4x2 for XQ/YQ or 1x2 LUT mode, 1x2 F56/wide/carry mode, 2x2 XQ/YQ unused or state use tag()/mark() bits for modifying display mode make comfort function for putting 4x4 pixel font text into LUTs this will give possibility of labeling parts of design, better than tag() static display of chip config, but later dynamic run chip and display, debug possible run it in webserver mode, with browser as interface, else X progr later possibly convert this tool into an FPGA editor would have to derive routing on loading from the PIPs, reroute on LC move wait with doing libvirtex project until got hardware and can use it from JBits then I have BRAM/IOB/download knowledge and can get own raw bitfiles 2001.07.14 Sat looked at XAPP130 (BRAM layout) and noticed it is pipelined needs clocking change, as I will be going to external memory, skip BRAMs 2001.07.17 Tue while at work musing on doing an "chip photo" display program from XAPP151 info with CLB = 4x4bit/8x8 pixel, so BRAMs are 10x24bit/20x48pixel space aim for colour styling like that seen in microscope images http://micro.magnet.fsu.edu/chipshots/index.html 0=cyan, 1=yellow style, good red/blue invert, blue grid, green neutral will definitely have to make such an tool 2001.07.25 Wed for chip display it would be nice to have comments in the chip coded 4x4 pixel in 16bit int font, for putting text patterns in LUTs 2001.08.08 Web Mail from Xilinx that there is now an JBits discussion list jbits@yahoogroups.com, subscribed to it 2001.08.15 Wed officially opened subproject to make an "chip photo" viewing tool named this tool VirtexView, command vv created VirtexView project directory and started logfile http://neil.franklin.ch/Projects/VirtexView/Logfile will implement it after reaching PDP-10 2nd milestone test compile in LogicFunctBuf0Irop3 getting strange error message: com.xilinx.JRoute2.Virtex.RouteException: Unable to route sink CLB(18,11,S0_F1) other 3 buffers are OK, also 2 buffers in Atest, also with IrmaOut[3] moving LogicFunctBuf0Irop3 after LogicFunctBuf3Irop6 moves error also the other w (4..6) route as they are supposed to send mail to JBits@yahoogroups.com to see if anyone knows what is up 2001.08.16 Thu mail answer from Xilinx, suspect routing resources all used up test with jroute.getFanoutRouter().debug = true; sent test result back to Xilinx, also dumped pre-crash bitfile and sent that all Output Muxes used up, JBits routes every route from out, no Mux reuse must make Pin array as target for each IrmaOut and just route that once 2001.08.20 Mon further mail answer from Xilinx about situation, suggest using cores+Nets+Buses but I do not comprehend the documentation for that, also big style change simulate with Pin array, this make array of large size then when all Pins there copy to an fitting sized array and route that alternatively hand use horizontal longlines, hand route output once to them then route all LUT inputs from longlines for this Xilinx says I need to use ResourceFactory to reserve resources unfortunately JBits does not regard longlines as place and route-to resources need to select and set all routing PIPs by hand, lot of work once again see the limits of close-source software, no small modification to either improve routing or make longlines explicite elements libvirtex will implement the longlines method 2001.08.29 Wed Alan Nishioka discussion of .bit file format, is more than just XAPP151 data http://neil.franklin.ch/Usenet/comp.arch.fpga/20010828_download_bitstream_to_FPGA 2001.09.03 Mon 2001.09.03 Mon khtsoi@pc90026.cse.cuhk.edu.hk published Linux parallel port download program http://neil.franklin.ch/Usenet/comp.arch.fpga/20010903_Linux_download_bitstream_w_source there are only 12 horizontal longlines per CLB, only 2 drivable per CLB http://neil.franklin.ch/Usenet/comp.arch.fpga/20010903_Virtex_Architecture_Interconnect so additionally to work, collision if MemOut and IrmaOut are 6 CLBs distant longlines seem to have been reduced to nearly as useless as tristate lines make libvirtex routing with single/hex lines unless large longline advantage consequently no special user-level longline allocation 2001.09.05 Wed will try variant with Pin array as it is a lot less work avoid copying by using fitting array, but needs adjusting for new connections 9 bits of IrmaBus Pin array and IrmaPos int for allocationg space in them only 9 bits, as AC/I/X/Y only in few places, use normal one-to-one routing leave IrmaOut->IrmaOld separate, fast connection and we can have 2 routings MdmSel*/AtestFunctBuf*/LogicFunctBuf* from 0..2/3..4/3..6 AtestInstr/LogicInstr from 0..2, AtestCond/Doit from 6..8 AtestCompare/JmpskipAddsub from 3..4/3..4/3, Logic* 5 times from 7..8 this bug that cost 3 weeks only exists because tool implementation broken can not be fixed because closed source, needs workaround, I need open tools download JBits 2.7, try install, fails like 2.6 and 2.61, Install friezes, del 2001.09.15 Sat thinking in bed about features for my tools VirtexView added ideas about text mode dump also debugger mode because BoardScope is not just bad display but also slow but this will require using an actual board to replace DeviceSimulator but connecting an board to BoardScope will require programming anyway static display is just an intermediate step towards debugger libvirtex decided to go for routing based on naming out pins, registering targets and route() this looks like perl would be ideal language, good project to learn it no compile/run, ideal as .bit generation only run once after each edit Lisp would also be nice for it, but too foreign for many potential users 2001.09.29 Sat Xilinx Mail announce of JBits 2.8, still mentions Linux and NT install troubles does not seem anything attempted to correct them, stay with 2.5 2001.10.01 Mon Discussion of XAPP151 control register flags, Virtex-E conf identical to Virtex http://neil.franklin.ch/Usenet/comp.arch.fpga/20011001_CTL_Register_in_Virtex_E_Configuration 2001.10.06 Sat made first 00README, 0FAQ and index.html.en files for the VirtexView website referenced project from projects directory index.html.* 2001.10.09 Tue Thread of resetting FPGAs without the logic going unsynced or metastable http://neil.franklin.ch/Usenet/comp.arch.fpga/20011008_FPGA_reset 2001.10.15 Mon comp.arch.fpga Discussion pointed to an JTAG downloader for Linux http://www.cse.cuhk.edu.hk/~khtsoi/project/Xilinux/ 2001.11.05 Mon continued testing Atest implementation, JUMP is correct CAI subtract is wrong, from bit 32 on, ...00110, for a while then again right bit 30: ... bit 31: I1=0, I2=0, LUT=1, cyin=0, XOR=1, MUXCY=cyin, cyout=0, cy borrow bit 32: I1=0, I2=1, LUT=0, cyin=1, XOR=1, MUXCY=in1, cyout=0, 0-1in borrow bit 33: I1=1, I2=0, LUT=0, cyin=1, XOR=1, MUXCY=in1, cyout=1, no borrow bit 34: I1=1, I2=0, LUT=0, cyin=1, XOR=1, MUXCY=in1, cyout=1, no borrow bit 35: I1=0, I2=0, LUT=1, cyin=1, XOR=0, MUXCY=cyin, cyout=1, no borrow cyin: BX=1 cyout=1, no borrow this analysis gives ...11110, exactly what should be, bit 32 doing borrow data I2 is OK (visible in Immed Mux FFs), for I1 set Logic always MemData, OK suspect obscure code problem or BoardScope/DeviceSimulator bug, Mail Xilinx 2001.11.11 Sun still waiting for Xilinx answer, give them 1 week until Mon in the meantime started work on VirtexView project started up vv.c, all header comments stuff, made comp script for compiling added both and vv binary to index.html.en for website defined chip constants array of structs for Virtex family and model variants document CLB and FF layout in CLB, derived from XAPP151 work on holiday comments showing desired output formats for text dump and graphics some formulas for finding CLBs in the many logic control bits 2001.11.14 Wed sent mail to Xilinx if my first mail has been lost 2001.11.15 Thu got answer, Mail was seen, may be lost internally 2001.11.16 Fri got answer, they think my code is right, also can not find an tool bug send test code, compiles here and makes different wrong result mail them URLs with .java/.class/.bit of test code and my code 2001.11.25 Sun still waiting for second Xilinx answer, sent "refresher" mail 2001.11.26 Mon installed Java 1.2.2 on now up to date patched Solaris 2.6 at work fetched JBits 2.8, ran installer, transfered result as .tar.gz to home Linux recompiled .java to .class, run to make .bit, tested that on 2.8 BS/DS exactly same wrong bit pattern, verified there are really proper input data mail to Xilinx describing that mail back suggests using new 2.8 feature check what the CLB inputs/outputs are, click on their name tags doing so shows wrong CLB input data on bit 3 (row 1 G2) from the Immed Mux data should be from ImmedOut bit 3 (row 1 S0_Y), but code has S0_X, bug! corrected that to Y, recompiled, works, was cut&paste F/X -> G/Y missed X->Y this bug that cost 3 weeks only happend because of F/G code duplication shows that I need to get F/G (and Sl0/Sl1) independant code fast as possible this would be the case if I used my own program development tools also shows that vd debugger will need this feature either from reading out all CLB in/out pins (does chip have this?) or from taking known FFs and computing (simulating) next clock values will need knowing chip structure, bitstream, to do either of these this info will have to come from libvirtex project, suggests merging them 2001.11.28 Wed thread about open source tool chains http://neil.franklin.ch/Usenet/comp.arch.fpga/20011128_Is_there_a_full_open_source_synthesis_path_for_any_FPGA personal mail from Xilinx with their position on bitfile reverse engineering do not want support nightmare, so secret, is not to protect designs will not help me by publishing it, but will/can not hinder by using law so this project can now be publically spoken of and displayed decided finally to make my own tool chain, this will be the main part of it may make an Virtex assembler, not just libvirtex, so project may change name do not yet mention in projects directory index.html.* 2001.12.16 Sun continued testing Atest implementation, CAI now works, CAM also SKIP should write C(AC), state atestwracc becomes properly active but at same time also atestinsget, missing invert on insacc input, corr, OK this was right in #state part, falsely copied to Fpga.set(... LUT. ...) shows up problem with JBits Java code bloat, many lines per single LUT shows that I need an programming tool that is more expressive once again tool frustrated, started thinking on how my tools should look copy C compiler gcc/f77/pascal/gcj + as + ld + gdb + timing(?) modularity VHDL/Verilog/ABEL/CUPL by others, vas assember, first 1 file later linker compilers -m arch generate assemb for mult FPGAs, Virtex uses vas backend assembler define an assembly language to describe designs use explicit placing controlled by next/jump LC/zigzag/column symbolic names for marking the the present LC position have option for generating asm listing files that show symbol->placing use explicit I1-I4 for LUT formulas, and separate route from name.X/Y/.. offer for loops and calculated indexes and names with arrays possibly handled by having macro facility expand to straight code linker merges object files from mult assembler/compiler sources but also have compilers with asm{} in their HLL source then to debug vv+vm+vd and for timing vt/vp from VirtexView project make libvirtex subpart of the vas assembler, so we need an new name or even merge this project with VirtexView so this project may still change its name, so not make it public yet 2002.01.10 Thu present Java code in PDP-10 too much details, F/G dependant, Sli 0/1 dependant needs higher abstraction level, get rid of such nitty-gritty details planning on how future code should look, intend assembler-like code labels to name LUTs, instructions set LUTs, activate features, wire inputs no execution, just description, so no loops to make repeated stuff rather use macro-like expansion to generate repeated code design language, look for Macro-10 manuals, found assembly language handbook http://www.spies.com/~aek/pdf/dec/pdp10/1973_AsmRef/00_1973AsmRef_SysRef.pdf but only the system reference part is there, not the macro and later parts temporarily change Java code to be position dependant but this at price of loads of arrays of constants, name[][] syntax decided to in this project definitely make an assembler, not just library allows user to handle less irrelevant details, concentrate more on design so the libvirtex name will have to be replaced, look for new name 2002.01.19 Sat looking for name for this project, and for project directory VirtexAsm is not general enough, as also linker etc, all to make bitstream VirtexTools suggests also post-bitfile-making stuff, this plus VirtexView Linux systems have Binutils for gasp/as/ar/ld/gprof stuff obvious name VirtexUtils, would also suggest VirtexView is in it but also suggests that these are only utilities for compiler writers VirtexGenerate is too long and too heavy VirtexGen too much lake chip generation, not generating bitfiles VirtexCode too much like "the code of", like a law decided to merge libvirtex and VirtexView projects into one, VirtexTools original reason for separating them was libvirtex secrecy, now not needed merged Logfile of the two of them, also took in some more PDP-10 Logfile expanded ex-VirtexView index.html file to entire merged projects renamed project directory to VirtexTools, also Link in projects index expanded ex-VirtexView OOREADME and OFAQ files to new merged project 2002.02.15 Fri thread about by PDP-10 project, discussion of knowledge and time restrictions mention my job change, more time for hobby, doing this project http://neil.franklin.ch/Usenet/alt.sys.pdp10/20020215_A_new_FPGA_housed_PDP_10 2002.02.20 Wed thread on getting into FPGA development, differences CPLDs to FPGAs http://neil.franklin.ch/Usenet/alt.sys.pdp10/20020220_Getting_started_desiging_CPU_s 2002.02.22 Fri Jacob Nelson diskussion about making own tools, about TTL style vs HDL style 2002.03.08 Fri project status split off "doing:" section from "todo:" section, as in PDP-10 2002.05.01 Wed changed to new 40% time job (before 80%), so now I have time to start but will wait until PDP-10 3rd milestone is finished, else that never will be 2002.05.14 Tue discussion on reverse engineering bitfile, yet annother :-) http://neil.franklin.ch/Usenet/comp.arch.fpga/20020513_Architecture_for_high_level_reconfigurable_computing moved Virtex-* files to here from PDP-10, symlinks there so that I can refer to the final URLs for them in one post 2002.06.07 Fr testing with BoardScope is slow on my AMD K6-2/350 colleague suggests remote usage of new Athlon XP 1700+ at work tested machine while at work an got 10 times spead 3s/cycle to 0.3s/cycle tried running it from home over 256k/64k cable modem and it is dirt slow takes about 1 minute to draw initial screen, about 20 to draw updates is problem with Java Swing draws into local buffer then copy over X and they dont seem to have heard of compressing the MBytes of bitmap 2002.06.14 Fri am presently contemplating change from Linux to NetBSD problem may be connecting FPGA programming circuits looked into how they are accessed under Linux: iopl() set to 3 opens ports then process can simply outb() and inb() direct to/from IO addresses BTW: the iopl() system call was added for XFree to access video card regs 2002.06.15 Sat found NetBSD equivalent of iopl(), it is called i386_iopl() so connecting an FPGA programmer is as easy as under Linux or even DOS 2002.06.22 Sat further attempts to use fast machine from office colleague suggested VNC, installed it, runs a lot faster than raw X but not really faster than running locally, but feels better result bits are here faster, but then still updates rest of window there is also low bandwidth optimised version called tightvnc, try that next comp compile times home K6-2/350 vs office Athlon XP 1700+, 7 times faster tried running it, WOW! near full speed as if local in front of the Athlon no flackering from screen updates any more, just solid drawing 2002.06.25 Tue PDP-10 reached 3rd milestone, so from now on this project is active 2002.06.27 Fri Christian Plessl reports on some readback ommisions in XAPP138 http://neil.franklin.ch/Usenet/comp.arch.fpga/20020626_Virtex_E_Readback 2002.07.02 Tue RCS archive set up, loaded with all source files so far, RCS revision 0.1 work will be 0.x, Milestones then x.0, further work x.x, same as in PDP-10 now that archiving works, replaced comp script with an Makefile in addition to making vv also put in ci target, broken as in PDP-10 2002.07.10 Wed PDP-10 planned post milestone 3 changes done, now ready for new features but first I want to improve documentation there, for that I need VirtexView also I want to start education colleagues on using FPGAs, that also needs vv so now I am going to work on this project for a bit, until enough is running decided to split VirtexView into 2 separate programs VirtexDump and VirtexView VirtexDump for textual output, VirtexView for graphical output as there will be 2 separate programs and vd will be the first one renamed vv* into vd* in working dir and RCS, changed name inside source modified index.html.en, 00README, 0FAQ, Makefile to reflect this changes reworked ideas on program options, changed output file -f -> -o, like cc does for this changed old -b/-o/-h to -t with b/o/h behind it, like od does it put in separate options for separate LUTs and FFs and entire CLB bits decided -m memory mode will be built in, not an external program with pipe added VirtexModels[] entries for Spartan-IIE and references to its data sheet archived as RCS revision 0.2 2002.07.22 Mon decided to treat BRAMcontrol and BRAMdata as one when dumping raw bits so BRAM in just data and raw mode use -b option instead of -d switched to consistent BRAMcontrol before BRAMdata arrangement switched few places in source and logfile to consistent row/slice/col/lut original design idea was extracting desired bits while read-in this looks like it will give complicated code, mix of read/shifts/selects ideal to make programming difficult and produce hidden bugs better first read in everything and cut out raw CLB/IOB/BRAM blocks then apply all precise cutting outs (and later modifications and write) started design data structure to hold FPGA bits in processing-friendly format present idea is CLB "long[48]" each "long" vertical with only 18 bits used then frameset IOBN+CLB[n]+IOBS, then matrix GCL+CLB[n]+IOBW+IOBE+BRAM[n] reread XAPP138 and XAPP151 started looking at JBits null300.bit and pdp10.bit files with "od -t x1" comparing what I see with the Alan Nishioka description of .bit fits apart from the lenght of data field 0x65 being 4 bytes documented header into vd.c source code, in form of global variables wrote readbitfileheader() to read in and validate header wrote readbitfile() which calls above, and added call to it into main() compiled, as suspected it will need big->little-endian conversion, by ntos*() also reading 9 header bytes as string falled, needs 2*long+char read 2002.07.23 Tue wrote readbitstreamheader() on base of XAPP138 20+21, tested OK renamed readbitfileheader()->readfileheader() and readbitstreamheader()->readstreamheader() for shorter names wrote readsetmodel() to set model constants based on length read from stream now we know device model, we can read into model dependant data structures reversed Rows/Columns to Colums/Rows in VirtexModel description, for consitency expanded to full set of Column/Row/Frames/Bits constants/variables constants as #defines, variables in VirtexModel, set by readsetmodel() started readmainframes(), done provisorical allocation of space 2002.08.01 Thu contemplating programming language choice, C has miserable string handling an better language would reduce work, particularly vm and vas parsing input but language must also be able to read/write binary files (.bit) and write graphic files (.png?) and be able to draw in X window for vdb perl may be capable, but colleage thinks not, no one could think of other experiment, write vd and ev vv in C and then redo it/them in perl and compare 2002.08.04 Sun continued on readmainframes(), decided on read entire frame, then extract after calculate sizes and allocated all memory for bitstream data parts read a frame, and convert entire frame to propper endianness tried to use Bitmap[Col][Row][Frame]= for converting, but compiler throws up can not know about sizes needed for calculating offsets, so use pointers 2002.08.05 Mon tidied up todo section in this file, added remarks on vv graphic output formats added remarks on vm -r and all Virtex-E only with -DRISK_* options 2002.08.17 Sat added #ifdef RISK_BROKEN_CHIP around all E and EM model definitions so for the moment they are not known, and will lead to "unknown model" error continued on readmainframes(), have code step straight though all frames have target pointers Middle and TopBot do complex stepping of Bitmap* targets in each frame run through target words, collecting bits from loaded frame added reading in also the empty pipelining frame and testing it for empty fails test, is because pipelining frame already read in loop, as last one test last read frame, instead of read one more, works do target stepping so that Bitmap*[0..columns-1][0..rows-1][0..frames-1] as reading framewise, all rows in one, step in "frames" amount 2002.08.18 Sun continued on readmainframes(), stepping TopBot and Middle by number of frames this jumps over all the space for the other frames of each element use TopBot += FramesInElement; and Middle += FramesInElement; at end of an frame must correct it back to original state plus one word use FirstMiddle = Middle; FirstTopBot = TopBot; and Middle = FirstMiddle+1; TopBot = FirstTopBot+1; at this state was last backup, see below for its use at end of frames from one column (Center or CLB or IOB W/E or BRAMcontrol) must correct for frame stepping, to hit next group of words moved all of this target computation before copying, so that Frame is right else it would calculate using Frame from last one, need Frame+1 added BitmapPipe and BitmapPadPipe to store the empty frame, else segfault also moved initialisation from before loop into target computation using if (Frame == 0) to only do it once, makes code less scattered also all variables for targetting can be declared in the loop, better with Bits variable in loop, move empty pipelining test into loop use if (Frame == VirtexModel->MainFrames-1) for last frame Middle and TopBot use separate StepMiddle and StepTopBot, not FramesInElement is because frame row stepping is further, full columns*frames rename *Element to *Column, as that is what such an groups of Frames are target calculation should be OK, without correction after column test shows that it segfaults as soon as it starts writing to BitmapBramC is only VirtexModel->BramCRows space allocated, not * VirtexClbsPerBram here see larger changes with above and with BramC and BramD to combined Bram so the present state needs to be saved, today already quite a bit of change fetched back lsst Backup and retroactively archived as RCS revision 0.3 present state archived as RCS revision 0.4 2002.08.26 Mon changed virtex_em into virtex_e_em, as they are Virtex-E extended memory musing on program mixed language usage, vd and vm surely C for all bit shifting vv perhaps perl using vd behind it, vas perhaps perl using vm as backend libvirtex then als split C lib for vd/vm and perl lib for vv/vas noticed no downloader in tools collection yet, added vdl VirtexDownloader updated "todo:" below, index.html, 00README and 0FAQ but this split makes vdb slow, needs vdl->vd->vdb behind every readback while all C will allow one program that just calls functions, shared Bitmap 2002.08.27 Tue rechecked manual, Virtex-E extended memory are referred to as Virtex-EM even though they have XCV00E numbers, changed edit back to virtex_em added comments documenting my assumptions on series differences and predictions about what will be supported when 2002.08.28 Wed re-ordered Virtex chip architecture constants by horizontal and vertical added constants for hor/vert amount of LUTs/IOs in CLBs/IOBs separated Virtex series definitions from chip model definitions standardised naming series/families -> series standardised naming models/members/sizes -> models separated allocating Bitmap memory from read in, to allocframes() renamed VirtexModel pointer to Model, makes code more readable renamed readsetmodel() to setmodelfromconfigsize() as no reading is done like allocframes() this can also be used when generating from scratch reorganised BRAM handling, BramC and BramD -> Bram this simplyfies variable names, makes code more readable unless only control or data subset is wanted, for those just Bram[C|D]Frames dito Pipe split to PipeM and PipeB and then summmed as Pipe mended allocation to use Model->BramRows*VirtexClbsPerBram, so enough space no segmentation fault any more because we now have enough space but now can't find model, was BramFrames instead of BramCFrames in size calc setmodelfromconfigsize() rid of struct VirtexModel Virtex, directly use Model for FrameBits calc use Center/Gclk, not Clb/IobNS, for this compute first added BUGCHECK tests for expected inputs, puts() fatal error and abort() present state archived as RCS revision 0.5 2002.08.31 Sat continued on readmainframes(), revised calculating target addresses for loading added test for pipelinig word being zero, like testing for pipeline frame got rid of the awfull, ever lengthening First*Frame calculation done so by having each step calculate when next step, as Frame+frames split "next column" into separate ones for CLB, IOB W/E and BRAM control stepping through rows is only a step by "frames", not "cols*frames" as all rows of one column are direct behind each other for [col][row][fr] all of a sudden I have got Segmentation Fault, in the free(FileFrame) ! looks like something is getting overwritten, most likey pointer misscalc Attila on IRC suggested using efence to trace it, that uses no-access pages fetched, compiled and installed it, crashes out with "Allocating 0 bytes" was nothing to do with pointer calculation, but rather allocation size found not initialised variable Model->PipeRows, that was it, works now this error never showed until now, despite being a few days old must have been because other alloced space was being missused suggests we were up to now never computing the right address for Pipe bramc is being triggered on frame 1 and all 27 following is because NextBramCColFrame had 1 in it, zero all the First* and Next* 2002.09.01 Sun present state archived as RCS revision 0.6 continued on readmainframes(), de-interleave target addresses in CLBs/... Middle an TopBot do not start at Bitmap* but at half-width offset from it then do not step monotonously upwards, but rather jump left/right growing no separate cases for First*Frame (set Middle and TopBot) and Next*ColFrame (step Middle and TopBot), as stepping is complicated rather one case which recalculates Middle and TopBot each time calculate from Frame->PhysColumn->LogColumn got a bug because C auto-multiplies an summand to an long ptr by sizeof(long) bit arrangement within an "long" should be OK, top of CLB = bit 31 (top/MSB) but frames are being written top (= n-1) row into first (= 0) row index better commenting of how Bitmap* is organised added comment about using longs, moved VirtexBitsMask and BitsInLong here VirtexBitsMask is not a constant from Virtex architecture, renamed BitmapMask 2002.09.02 Mon continued on readmainframes(), need to reverse row order in Bitmap* add (rows-1)*frames to pointer for beginning, and step by -frames moved First*Frame and Next*ColFrame stuff after Moddle/TopBot/Step* calc as it is used after this loop iteration, for setting up next one test segfaults at Bram, is missing *VirtexClbsPerBram factor in Middle/TopBot segfaults still, BitmapDll should not have *VirtexClbsPerBram correction segfaults still, StepMiddle should not have *VirtexClbsPerBram only the Bram beginning calc needs one, then it works this is 3rd bug due to missing this scaling factor, need to eliminate it replace with VirtexBramQRows (Q for Quater), no factor use, simpler code the entire VirtexClbsPerBram factor shall only appear in processing BRAMs replace Virtex*Bits with only VirtexMiddleBits and VirtexTopBotBits and Virtex*Rows with only VirtexMiddleRows and VirtexTopBotRows this has reduced size of #defines and struct VirtexModel quite considerably moved pipeline word empty test to after extracting, as it is only met then decided to not store pipeline frames, as are only zero in them, save code got rid of BitmapPipe and BitmapPadPipe and all *Pipe* constants got rid of FirstPipeFrame, using now Model->MainFrames-1 also no calculation of Middle and TopBot and Step* for Pipeline frame because of this after testing frame for zero break out of for () loop moved read in before target calculation, no Pipeline in target base calc because larger changes yesterdays state archived as RCS revision 0.7 2002.09.04 Wed retroactively index.html.en, 00README, 0FAQ archived as RCS revision 0.5 expanded log string in vd.c, put entire log in these 3 improved commenting a bit improved file header and bitstream header plausibility tests a bit setmodelfromconfigsize() BUGCHECK correct test StreamFdatinLen not StreamWords moved all .bit file open/close/error stuff from readbitfile() to main() readbitfile() is now FILE Bitfile in, ret char error, like all other read*() moved all BitsInLong and BitmapMask into readmainframes(), where they are used renamed BitmapMask to BitsMask to fit naming here, as not in Bitmap defined dumpbits() which just selects dumpclbs() or dumpluts() to do work will later use the user-selection what is to be dumped put remaining comments on LUTs in CLB layout and dump format in dumpluts() started dumpclbs(), initially just dump one, given by Col and Row variables for () running through BitMask 0x80000000 -> 0x00004000 fails because long is -2^31 .. 2^31-1, need unsigned long everywhere for Bits added typedefs for uchar, ushart, uint and ulong, converted all Bits vars for () now enters, but runs endless, BitMask>>1 needs to be BitMask>>=1 now I get 18 lines of 48 "1" and "0" bists all 4x16 LUTs are set to 1, all 4 FFs are set to 0, rest looks consistent so I will assume this to be an CLB, bit read in and unpacking working right added output of frame and bit addr, and comment what CLB is being dumped split dumpclbs() into dumpclbs() which just decides which CLBs to dump and dumpclb() that actually dumps one single CLB, taking Col/Row as input dumpclb() added tests for range of Col and Row, BUGCHECK if outside started dumpluts() copy of dumpclbs(), but also knows Slice 1/0 and Lut F=0/G=1 an does not insert empty lines, as only one line per LUT dumped started dumplut() analog dumpclb(), but picks just LUT and FF bits for output for this needs to also know about Slice 1/0 and LUT F/G, select diff bits provide 2 different output formats, long (needs awk) and short (for cut) will later use the user selection what format is to be dumped also made FF part facultative, for just LUTs or with FFs present state archived as RCS revision 0.8 2002.09.06 Fri mentioning the Virtex-II Platform FPGA handbook has info on configuration regs http://neil.franklin.ch/Usenet/comp.arch.fpga/20020906_Virtex_II_bit_file_and_strange_configuration_command this for Virtex is in XAPP151, so this may be an partial XAPP151 for VII 2002.09.10 Tue went and fetched the Virtex-II Platform FPGA handbook, is partial XAPP151 f VII but a lot of detail is missing, some can be derived from data here config is 32bit words, frame (row+2)*80+32 no filler as 2n*80 is m*32 80x22 bits per CLB and IOB-N/S, 4*80x86 for BRAM, assume 64 data and 22 ctrl leaves 34 frames for center and 2*IOB-W/E and possible pipe frame frames all loaded in one go, no BRAM data separate, no info on what when will need an actual .bit file to analyse and pick out, from pattern mapping dumplut() some of the BUGCHECKs still print out dumpclb(), corrected started getoptions(), will take argc/argv from main, set globals for rest name of bitfile will be an option, should be global variable in opt section so can not be known in main(), readbitfile() must open/close for consistency dumpbits(() should also take no file from main() Opt* global vars and Opt** #defines to set them with replaced all if (0) and if (1) with if (Opt* == Opt**) checks 2002.09.11 Wed analog to readbitfile() rename dumpbits() to dumpoutfile() rename also Dumpfile to Outfile wherever used getoptions() and dumpoutfile() print output have getoptions()/readbitfile()/dumpsoutfile() print errors and direct exit main only consist of calls to them 3 and exit(0) if successfull getoptions() parse options, assign first (invocation command) in OptProgName parse rest of line words with for (argv) loop, no need for argc if first char is '-' it is an option, set fitting Opt* variable options -r raw, -s short, -l long, -w without FF, -f with FF else it is a filename, set OptBitfileName to the given filename changed readbitfile() to test for OptBitfileName = NULL and use stdin if so no filename on command line, default NULL, use stdin, delete test.bit link noticed on testing that PDP-10 bottom-left appears with 0x0000, wrong suspect column de-interleaving wrong, test when range select works option -o out to set OptOutfileName, dumpoutfile() test not NULL and open noticed that all output still goes to stdout, used printf() not fprintf() dito quite a few error messages go to stdout, should be stderr, fprintf() option -q quiet, just the actual data, no other stuff in raw surpress header lines (col/row), row numbering and footer line in non-raw surpress field labels, col/sli/row/LUT, ':'s and commas both -q and -sq become the same thing, treat it as 3rd case, not 2*2 cases option -v verbose, print out running report of what we are doing to stderr option -h help, print out an short overview of command line parameters help prints out [-rslwfqvh], program wanted separate -? -? -?, fixed progr dumpclb() added ASCII-Art lines .----- at top and | at left of data 2002.09.14 Sat converted all dump*() to return void, no validity tests that return errors only BUGCHECK tests that immediately abort program no serror = and tests for it in dumpoutfile() getoptions() add code to detect range parameter (first beginning with 0-9) reorganised so that after options only 1 range and 1 filename allowed prevent multiple filenames (would have overwritten), give error/help also test for unknown options, also give error/help big changes in newly written and not archived code in getoptions() retroactively archived last backup state as RCS revision 0.9 reworked help text for more detail, changes so it can go to stdout or stderr -h sends to stdout (easy redirectable), error to stderr (as supposed to be) make Bitfile and Outfile into global variables, they are implied anyway so no need of passing them to functions(), less code, more readable add SLIL and SLIR to existing SLI0 and SLI1, use the new ones, better readable dumpluts() start interpreting OptRange and then use for () { dumplut() } wrote range string interpreter, then for {for {for {for {dumplut()}}}} in the second for with Sli need to use Sli--, as it counts 1->0 dumpclbs() analog to dumpluts(); just with all Sli/Lut stuff removed added an specifig error test and message if L R F or G appear in range string while testing dumpclbs() crashed into an "out of range" BUGCHECK needs tests for user giving wrong data and error message added these to both dumpluts() and dumpclbs(), give valid range and error while testing dumpclbs() noticed that any -* range simply hangs was option processing, make -[0-9] break option loop, then go on to range now -60/35 does not fail with range error, runs simply to maximums is not entering range processing in dumpluts(), OptRange is NULL is because test for "is it an range" is failling is because "break is only terminating inner for () not the while () back to processing -[0-9] in option loop, now works, strange thing before test 0/9-/10 works, but /10 fails, regards that as filename, real name too much also test for /[0-9] and process that as range, not as filename and -/[0-9] also fails, add test case for it to getoptions() dumpluts() now nicely works, but dumpclbs() lacks its empty lines between added an fprintf() with test for not last Col and Row present state archived as RCS revision 0.10 looked into displaying pdp10.bit, vd gives 0x0000 for all LUTs vd -r shows actual variations, test case 2/3 shows LG = 0x0000 and others not so is a problem with the "cooked" mode, extracting the 4*16 bits from CLBs tested with printf-s, is a comment started with /* but ended with *) so the entire LutVal loop is not in the compiled code, so it stays 0x0000 now LutVal has data, but it is inverted, despite the &0xFFFF bit tested with printf-s, is the &0xFFFF that is not inverting, should be ^ (XOR) 2002.09.15 Sun renamed the -r raw option to -e entire, so thar -r can be used for row reverse test rows downcounting, again misstyped command as 0L/4-2 for 0L/4-/2 seems that this is not instinctive, "-" fit neared to each other than "/" so better use an col-col/row-row format, more user friendly changing duplicated code shows bad maintainability, separate setclbrange() while at improving, do dumpclb*()->dumpentireclb*(), dumplut*()->dumpclb*() rework setclbrange() col/row-col/row -> col-col/row-row correct option processing, no -/[0-9] any more, as - always has "end" correct range processing, / with - after it is possible, only "top" given problem with 0L-2/0 only all "L"s, no "R"s, 0R-2/0 only "R"s, no 1L-2 begin R, end L, bottom G, top F should cut out first/last half of f/l CLB set FirstSli, LastSli, FirstLut, LastLut begin L, end R, bottom F, top G should restrict all CLBs to only that half set OnlySli and OnlyLut, so that for () is collapsed for left+right vs one and bottom+top vs one select on *BOTH if both then possibly surpress one on first or last run for easier reading split Row/Lut processing from Col/Sli to dumpclbcol() decided to not have -r reverse row option, would have switched to top->bottom vd shall always do bottom->top (use), while vv does top->bottom (layout) use now free option -r for range, no [0-9] heuristic with - and / exceptions only simple -r test with OptRange = , no break, no tests after options present state archived as RCS revision 0.11 noticed that -e still uses OptHeader that is never set, use OptFormat, all 3 started with memory mode, decided on what options should look like added -m, -z and -t to getoptions() and help, eval to dumpoutfile() dumpmemoryclbs() identical to dumpclbs(), to get column/slice dumpmemoryclbcol() similar to dumpclbcol() but iterates through LutFrameNo dumpmemorylutframe() derived from dumpclb() but iterates through Row/Lut changed dumpclb() to also loop through FrameNo, not Frame same also to dumpentireclb(), for consistency with dumpmemorylutframe() actual outputting of bits is more like that in dumpentireclb(), single bits Row has to run top->bottom, as that is MSB->LSB, presently only binary Lut both/F/G same as in dumpclbcol() with dumpclb() -> fprintf() need LutAddress 0..15, changed dumpmemoryclbcol() to always deliver that rename to dumpmemorylutaddress(), converts this to LutFrameNo, using Sli better dumpentireclb() works with 2 for()s Bit and FrameNo, so dumpmemorylutaddress() into dumpmemoryclbcol(() with Address and Row/Lut make decoration, -l addresses, -s and -l headers Makefile added tar target, to make .tar.gz archive for easy download of entire project, refer to it in index.html.en present state archived as RCS revision 0.12 2002.09.16 Mon changed some options, dropped -l long (is default) new -l LUT-only (was -w without FF), -f new FF-only (not with FF, is default) for -f and -l corrected output to show fixed + lutpart + separator +ffpart in vd -mqr 2L/0-17 pdp10.bit (fast memory) noticed some missing ones: addr 3 bit 34, addr 8 bit 35, addr 15 bit 34, leave until zigzag test memory reordered test in dumpoutfile() and code to be same, entire, memory, LUT+FF 2002.09.18 Wed split Row/Lut handling out of dumpmemoryclbsli(), rename to dumpmemoryclb() this gets rid of the awkward first/last LUT stuff and tripple repeat code dumpmemoryclb() rework into more modular code controlled by MemWidth (for malloc()s) and MemBit for indexing first print into word-width char arrays, doing transposition (90deg rotation) at end then simply print out arrays in proper row changed dumpentireclb() to also write each line into char array, one printf() dumpmemoryclb() add before output reformatting according to OptMemoryBase first split each memory word into bytes, separated by spaces -t *C 8bit, -t *S 16bit, -t *L 32bit, -t *[0-9].. nbit, -t -I word bytes formatting code is becoming large, separte routine formatmemoryclbs() then convert each bytes bits into char/octal/hex/decimal -t b bin (def), -t c char, -t d sig dec, -t o oct, -t u unsig dec, -t x hex -t c sets byte size to 8, as it only displays one char signed decimal can not be converted without losing fixed length of output and strtoul does not provide sign extension anyway would be lot of implementation work for next to no value, so drop signed present state archived as RCS revision 0.13 2002.09.19 Thu some tidying up of comments formatmemoryclbs() and setclbrange() added BUGCHECKs HeaderLine[4] make full line, not broken, fill it with strlen(HL[]) times '-' better generate it when outputting, together with ' .', from strlen(HL[3]) so no need for own HL[4] variable, only [0]..3[3] formatmemoryclbs() header no HeaderLoop == 4 ? '-' : ' ' special case formatmemoryclbs() put HeaderLine (aux) after MemWord (main) made HeaderLine facultative (by test for NULL), no test for OptLongFormat in dumpmemoryclb() test for OptLongFormat, call with NULL if not 2002.09.20 Fri formatmemoryclbs() added int Words and int Lines so that it is flexible for LUT-RAM32 and BRAMdata, renamed to formatmemory() because not CLB-only added further BUGCHECK for NULL memory or 0 memory lines moved 32bit byte test to base conversion, after test, as binary not limited 'c' format for 0..31+127 put ASCII name in there, rest char and ' ' output is actually more like "od" a, not c, rename, leave c as alias present state archived as RCS revision 0.14 started on LUT-RAM32 zigzagged memory dump, dumpmemoryzzclb*() select an pair of Col/Sli, one Col/Sli each for 0/2/.. and 1/3/.. bits always entire Row as an single bit uses F and G LUT for addr 0-15 and 16-31 surprising series of Segfaults in HeaderLine[][]= and MemWord[][]= wandered about when inserting printf()s, urgh was HeaderLine[] and MemWord[] pointer arrays getting overwritten all of a sudden disappeared, not reappeared, no source found test 1/0-17 works 1L+1R, 1L/0-17 gives 1L+2L, 1R/0-17 gives nothing bug in LastCol calculation, mistakenly used LastCol-1, is really LastCol made MemWidth and MemBit into local variables, pass in calls check up on the "missing ones" problem in 2L/0-17 memory addr 3 bit 34, addr 8 bit 35, addr 15 bit 34, leave until zigzag test memory checked no 1/0-17, also missing bits in here addr 3 bit 34, addr 7 bit 34, addr 9 bit 2, addr 18 bit 34, addr 25 bit 2 also only 1s missing, not 0s 2002.09.21 Sat "missing ones" problem, do tests with pdp10.mem set to all 0s and all 1s all 0s produces an all 0s memory output, no false 1s all 1s produces mostly 1s, but a few 0s, surprisingly only at MSB and LSB all broken bits are in CLB rows 0 and 16, all others are OK same bug shows (as too many 1s) in entire CLB view of 1/0, 1/16, 2/0, 2/16 R half of 2/0 and 2/16 seem OK, but 2R/0-17 shows 2/16 too many 1s checked rest of circuit (exept memory, as not regular repeats), same Rows rows 0 and 16 are 16*18bit = 9*32bit appart, suggests problem with read-in problem may hit other CLBs also, but not in their LUT bits, 2 shift per row 0 and 16 are exactly the rows where the 18bits are the first 18 of an word no bits left over from previous word (happens at 1(IOB)+Rows-CLB == n*16+1) 2/16 frame 6 is from frame 2072+6 10th word, has 8113e040, becomes 913fc... so it has broken bits all through this CLB, 3, 10, 12, 13 10, 12, 13 are also all 1 for all 48 frames, not so in 2/15 and 2/14 2/15 and 2/14 same frame all bits OK, so seems to be special case of word bug is in readmainframes(), "MiddleRows" for() loop, ulong FirstPart = for the case BitsLeft == 0, it should shift left 32bit and give 0 instead simply does not shift, leaving all 32 bits there, i.e. doing nop looked at generated assembler code, uses an sall (shift arith left long) this both for my gcc egcs-2.91.66 and the gcc 2.95.4 on machine at work made workaround if (BitsLeft == 0) special case code, no FirstPart and <<32 2002.09.22 Sun reworked this Logfiles "todo" section extensive, together with PDP-10 "todo" synchronised planning for future interaction of both projects added remark about no intended support for Virtex-II and Virtex-IIpro these would be subject to an separate Virtex2Tools project rename -t base hex from x to h because too many misstypings, allow x as alias test thoroughly before milestone, -h still in "Usage:" had -w not -l -v text first line had senseless ":" at end, reworded it apart from this all options seem to work, at least in desired combinations undesired comb: -em the -e overrides, I prefer the later/special -m to do so moved all dumpentire*() after all dumpmemory*() stuff dito all dumpmemoryzz*() before all dumpmemory*() stuff undesired comb: -lf both LUTs and FFs gone, because implemented as suppress this would surprise user, change -h to present this as their behaviour when both, result just Col/Sli/Row enumerate, get rid of trailing comma desired combination fails: -f and -s prints F/G, not X/Y letters should be in if() part of -s, like done in "long" format made an man page, documented complexities of -r "range" and bugs of -t formats fixed vd.c -h option to be more like man page added man page to index.html.en, dropped vd binary (user can compile) also moved obsolete comp script and Makefile to download section added man page to Makefile tar and ci targets removed using efence from Makefile, getting ready for release added an link to PDP-10 projects pdp10.bit file, as demo file renamed 00README and 0FAQ to README and FAQ, this is what people expect today same also in RCS archive with the *,v files changed references in README and FAQ, and in index.html.en and Makefile present state archived as RCS revision 0.15 added install target to Makefile, using PREFIX = /usr/Local made INSTALL installation guide, added to Makefile/README/index.html.en present state archived as RCS revision 0.16 as milestone 1 reached, make archive copy to ../VirtexTools/Milestone-20020922 moved old RCS into Milestone directory, will have new one starting -r1.0 renamed VirtexTools.tar.gz into VirtexTools-20020922.tar.gz updated index.html.en file with links to milestone files deleted obsolete comp script from new development version and from index.html.en and Makefile, re-added efence in Makefile make ci new RCS archive started up, starting at -r1.0 make tar generated new VirtexTools.tar.gz for test, downloaded VirtexTools-20020922.tar.gz into /usr/local/tar unpacked it into /usr/local/src, make, as root make install man vd works, rehash, vd -0L ~neil/htdocs/Projects/PDP-10/pdp10.bit works 2002.09.23 Mon vd.c renamed Column* -> Col*, Slice*->Sli* (Row and Lut are already 3-char) for consistency with the all-3-char names used in dump*() and pdp10.java and intended as naming style in libvirtex/virtex.h updated INSTALL to tell user to du man vd examples improved vd.1 to have a bit more meaningfull ranges in examples 2002.09.24 Tue split out include/typedef/prototype code common to vv.c and vd.c into virtex.h updated index.html.en to link it, dito Makefile ci and tar, and INSTALL planning on what stays in vd.c (duplicated in vv.c), what goes into libvirtex readbitfile() and all read*() subfunctions will go to libvirtex setmodelfromconfigsize() and allocframes() also remove OptBitfileName global that stays in vd.c from readbitfile() same also with if (OptOperation == OptVerboseOperation) tests readbitfile() now with char *BitfileName and int Verbose parameters move all if (OptOperation == OptVerboseOperation) into readbitfile() as OptBitfileName and Opt*Operation used in main() when calling, move there rename to Main*, while at it Main*Operation var and const to Main*Verbose for consistency do same changes to dumpoutfile(), Outfilename and Verbose setclbrange() will also go to libvirtex, so get rid of vd.c global OptRange also not use OptProgName here, rather gen rest of error message, to caller only BUGCHECKs/abort()s should be printed/done by libvirtex updated them to be totally clear technical messages (var names, values) formatmemory() MemWidth can be derived from str(MemWord[0]) so no separate parameter that need to be in every call to it fixed Makefile install so that it generates missing directories before using 2002.09.25 Wed BUGCHECK removed FATAL part, is obvious to target audience (programmers) removed helpoptions(), part of vd.c from setclbrange() for consistency also removed it from formatmemory() setclbrange() use an if (Range == NULL) { return; } style test consistency also move if (OptMemoryBase == NULL) test into formatmemory() because of this move FormatChar = *BaseOpt after test, not in var declarat don't abort when user error, pass error message back to caller change to char * return type for error message, exit(1)->return(ScrError) remove OptProgName from setclbrange() error handling, error string without it in dumpoutfile() test for error and output error message add OptProgName to all error messages in dumpoutfile() move error message printing out of readbitfile() into main() add OptProgName to readbitfile() error messages in main() because of this move/rename OptProgName to MainProgName split out code common for vv.c with vd.c into virtex.c (source for libvirtex) updated index.html.en to link it, Makefile extended ci, tar Makefile added compiling virtex.c->virtex.o archiving virtex.o->libvirtex.a changes INSTALL to only support .tar.gz download, no separates (too many) copy remaining vd.c to vv.c for further independant editing, and vd.1 to vv.1 eliminate unused parts (all memory/zigzag/type stuff) from vv.c and vv.1 updated index.html.en to link it, Makefile extended ci, tar, added vv.c Makefile added install of libvirtex started man page for libvirtex, install also as libvirtex.a and virtex.h and also added ci and tar of man page, added it also to index.html.en present state archived as RCS revision 1.1 20020928 Sat various code improvements, hide lots of detail in libvirtex, simplfy user code hardly any work donw in vv.c, only change in vd.c and then re-copy to vv.c hide all cases of Clb = BitmapClb+(Col .. Row) .. ; address calculation behind Clb = getclb(Col, Row) function just gives back pointer replace all cases of *(Clb+FrameNo) with an Clb[FrameNo], nicer code all CLB layout diagram and Lut*BitMask, FfBitMask in virtex.c put TopBitMask and BotBitMask, and also BitsMask in virtex.h put them up in *Bitmap section, as they come from the format used there hide all LUT and FF bit extraction/shifting behind LutVal = getlut(col, sli, row, lut) and FfVal = getff(col, sli, row, lut) dumpclb() reworked to use these functions hide entire frame/bit/bitmask extraction behind Bit = getclb(col, row, frame, bit), renamed above getclb() to findclb() dumpentireclb() and getlut()/getff() reworked to use this function findclb() now only used by getclb(), will stay so, so move it into there dump*memoryclb() use LutVal = getlut() and then extract bits from LutVal deleted referrences to XAPP 138/151 from vd.c, as is Frame/Bit/BitMask free BUGCHECK for Model and BitmapClb in getclb(), not in the multiple dump*clb()s Bitmap* not as extern in virtex.h, as not used BUGCHECK for Col/Sli/Row/Lut in dump*clb() unneccessary, setclbrage does it BUGCHECK for Model in dump*clb() only for Model->Col/Row BUGCHECK, delete BUGCHECK for Outfile is superfluous, as fprintf(Outfile...) will scream only 1 BUGCHECK remaining in formatmemory(), for MemWord and Words, delete so there are now only BUGCHECKS in virtex.c (library), not it vd.c and vv.c Model now only mentioned in /* expects: */ in dump*clb(), delete them only 1 /* expects: */ remaining in formatmemory(), for OptMemoryBase OptMemoryBase only sets Base, do so via call parameter, not global so there are now only /* expects:, leaves: */ in virtex.c (library) wanted to move *Frame and *Bits to virtex.c, but dumpentireclb() uses then present state archived as RCS revision 1.2 re-ordered dump*clbs()s and dump*clb()s to normal, entire, memory, memoryzz the whole SLIBOTH/LUTBOTH and OnlySli/OnlyLut business is a total mess redesign it, so that Sli/Lut can be for()-looped like Col/Row use First/Last-Sli/Lut for when only one type to be used use Begin/End-Sli/Lut for when single first or last are to be dropped dumpclbs() now single step, like dumpentireclbs(), no dumpclbslis() same eliminate dumpmemoryclbslis() and dumpmemoryzzclbslis() dumpmemoryclbs() move MemWidth and MemBit into dumpmemoryclb(), no parameters same for dumpmemoryzzclbs() to dumpmemoryzzclb(), gen [Col/Sli][0/1] there present state archived as RCS revision 1.3 2002.09.29 Sun further code improvements rename dumpclb() to dumplcell(), as that is what it does, dumpentire*() stays dumpmemoryclb() to dumpmemorylut(), dumpmemoryzzclb() to dumpmemoryzzsli() dumpmemory*() per LUT call with "if first/if last" is ugly and problematic dumpmemoryclbs() only Col/Sli looping, Row/Lut loop inside main routine makes it dumpmemorystripe(int Col, int Sli) same for dumpmemoryzz*(), get rid of awkward dual call to dumpmemoryzzsli() Sli also count 0->1, despite internal numbering, else bug source so SLIL=SLI1=0 and SLIR=SLI0=1, so we can use <= and ++ in for() loops global vars Col/Sli/Row/Lut not needed in dump*() calls, make them void reduce user code size, getclb() use implicit Col/Row/Frame/Bit dito getlut(), getff() use implicit Col/Sli/Row/Lut because of this change dumpmemoryzzstripe() zigzag Col and Sli (re-)copy remaining vd.c to vv.c for further independant editing eliminate unused parts (memory/zigzag/type stuff) from vv.c, more than 1/2 rename all occurances of "dump" in vv.c to "view" vv uses graphic output, so only fprintf() bits, no texts (later use an font) so presently ignore short and quiet modes, make only quiet mode viewentireclbs() did -e entire CLB , as 48x18 bitmap, using -a ASCII output draw rows top->bottom and inside that columns left->right experimented with ASCII chars, . and %, 0 and 1, O and X, . and M, . and 1 viewclbs() extract LUTs and format them for output, as 4 lines of 4 bits LUT bit arrangement 0123/4567/89AB/CDEF, LUTs arranged S1G,S0G/S1F,S0F only 1 space horizontally is too little, put in 2 spaces, it looks better now change to same 2 space output in viewentireclbs(), also looks better want to use OptFormat for switching -a ASCII vs default .ppm so rename -q/-s OptFormat to OptDecoration in vd.c and vv.c and rename format to decoration in helpoptions() and man pages option processing for -a ASCII format, for ASCII graphic output for non-ASCII presently no code there, will need writing as next present state archived as RCS revision 1.4 separate out all test ASCII/binary and actual implementation into outpixline() for an empty line call it with NULL, else with and LineOfPix string rename LineOfBits into LineOfPix, set to '0' and '1', and use single spaces in outpixline() if ASCII convert '0' to '.' and extend to 2 spaces bitmap graphics format, done a bit of investigation into .ppm format P3\n \n\n then many lines of pixels as <...>, \n when needed bit-per-pixel-channel=1 gives 6 chars per pixel, 8 pixels 48 chars per line OTOH I do not have an easy description of .png or .tiff do not want .gif and have no description anyway so use .ppm despite size (XCV300 is 6144 LUTs, 153600 pixels, 921600 bytes) implement .ppm output, generate header and lines of 8 pixels/file-line header needs number of graphic-lines, can not be derived from LineOfPix outpicinit() function, call from view*clbs() with no of lines rename outpixline()->outpicline() and LineOfPix->PicLine 2002.09.30 Mon looking at how to implement LUT vs FF vs LUT+FF display in vv.c, and do -l/-f are FFs even interesting, did vd -l pdp10.bit, and noticed not one set FF -> eliminate FF display from vd and vv, eliminate -l and -f, leave getff() change title to "dump/view of LUTs and BRAMdatas", no FFs or IO-FFs vd.c dumplcell()->dumplut() and dumpmemory*stripe()->dumpmemory*lutstripe() outpicinit(Height)->outpicheader(Width, Height) and added outpicfooter() viewclbs() and viewentireclbs() calculate Slis/Luts and Cols/Rows also use these for allocating PicLine[], PicLine memset() change to '= 0' now that view*clbs() knows Width, it can generate Width space for horiz separ outpicline() get rid of NULL special case, just straight forward output move outpicline() first call stuff into outpicopen() rewrote messy ASCII variant of outpicline(), compacter, readable and faster present state archived as RCS revision 1.5 view*stripe() replaced awfull index calculation stuff with *Pixel++ put getlut() direct into formula, no intermediate LutVal variable LutBitRow as local variable, passed as parameter to viewstripe() rename to BitQuartet, and LutBitCol to BitNo outpicline() bitmap scale hight (line n times) and width (pixel n times) OutputSect 80 chars wide, dynamically fit no of pixels (ScaleWidth*6 chars) experimented with different settings, 2x2 gives best, 2x3 feels stretched option -p pixel/pixel scaling (default 2x2) implemented, in outpicheader() -e entire CLB bitmap is squashed due to 48x18 bits, should be 2x3 ratio using -p 1x4 makes 48x72 = 2x3, but bits become vertical stripes option -et true layout that inserts 3 blank lines after each bit line with -p 2 it gives large picture, automagically -p 1, do this for all -e option -ef folded layout (48/2)x(18*2) = 24x36, half size of true layout 2002.10.01 Tue decided there will be no colour setting option, use graphics postprocessor corrected helpoptions and man pages to show combined options as -mz -et -ef put styles like -s/-q and -a after basics -e*/-m*, together with -v eliminated referrences to -l and -f, logic cell -> LUT corrected man page for vv, dump -> view, lines -> pixels completed man page for vv, with examples for -et, -ef, -p -a fixed bug, horizontal scaling is not allowed to be more than 13 (=int(79/6)) corrected 80->79 (no newline bugs) while at it, and #defines for 79 and 6 decided to do vd and vv extentions to BRAMs etc before vm modifier Makefile added uninstall target, mentioned uninstall in INSTALL create project webpage logo, vt-logo.java, from massivly cut down pdp10.java javac complains '-' not allowed in class (and file) names, grrr, vtlogo.java javac compile to vtlogo.class, java run to vtlogo.bit, vv | display, OK some glyphs do not look optimal, so print entire ASCII 0..127, revise font in particular $ - . 7 8 M V W Y, also add small letters, as bad as they are made large text "VirtexTools" with each char 5x7 of the small chars intended to put a few lines of single char text below, but they will be small so only make the one text, cut down range to text + 1 CLB surrounding space Makefile added vtlogo target, in ci and tar added vtlogo.java index.html.en, added link to vtlogo.java, added to vtlogo.png Netscape 4.7 displays the .png broken, black LUT separators missing tried newer ImageMagick (5.4.4 on maine, not my 4.2.2), it works now index.html.en at "Intended toolchain" now also "Implemented toolchain" sect 2002.10.03 Thu showed vv graphic to colleague at work, he immediately asked if colour change so an option for setting colour has got to go back in other colleague suggested an .rc file for users style preferences but better use an env var, containing options prepended to command line even better use an alias or shell function, no code needed to support this 2002.10.06 Sun separators in -e modes are too thin, particularly horizontal one gets missed make tham larger, tries 2 bor and 3 hor, now hor too beig, 2 and 2 is good -et is distorted and then crashes, crash is missing Pixel = PicLine; distortion was due to hor spacing between CLB rows, was still full width had before simply made 2 lines, now with 2 pixel was slightly more for numbering in long decoration, added font from vtlogo.java to libvirtex renamed WriteFont[] to LutFont[], and luttext() to lutchar() while at it long decoration increase Slis and Luts for more space implemented Row/Lut addressing at left of picture display it with 1 = '1' and 0 = ' ' so that uses background separator colour doesn't look good, 1 = '3', 0 = '2', add 2 separate colours for decoration ASCII mode format decoration with 1 = '#' and 0 = ' ' ASCII mode missreads deco starting with ' ' as empty line, test for full line but it also miss-expands ' ' inside LUT, so do not do that implemented Col/Sli addressing at top of picture in top/left corner 5x5 spaces, apart from "corner" between '-' and '|' as -l is not any more used for LUT only, now use it for long decoration now have symmetric -l/-s/-q, changed in vd.c, vv.c and man pages vd.1, vv.1 short decoration implemented, just one line at top with range in it present state archived as RCS revision 1.6 extract all BitQuartet and BitNo looping into lutstopiclines() also the entire 4x4 splitting stuff, and LUT vs decor pseudo-LUTs colouring renamed all view*stripe() into view*line() put generating horizontal separators into viewhorizseparator() same also entire mode horizontal separators into viewentirehorizseparator() viewentireline() extract OptLayout transformations to viewentirelayoutedline() reimplemented viewentirehorizseparator() using viewentirelayoutedline() made vd -z imply -mz and vv -t imply -et and vv -f imply -ef expanded vd.c/vv.c helpoptions() and man pages vd.1/vv.1 to mention this 2002.10.07 Mon changed -p (pixel) to -z (zoom), so -p is free to use for paint for -p (paint) moved colour definitions out into outpicheader() setup part outpicline() only references OutPpmColour[] array, no if/else analog also for ASCII format OutAscii[] array, no if/else colour setting -p option, helpoptions(), parse OptColour into OutPpmColour[] expand vv.1 man page to document -p option and how to use it while at it added in vd.1 and vv.1 the reserved options -cbidgn decided that when working on routing, route checks would be good added vrc VirtexRoutingChecker, updated "todo:" below, index.html, 00README viewentirehorizseparator() using viewentirelayoutedline() looks bad only for folded use it, for true and normal use direct outpicline(PicLine)s mused on implementing -l and -s for entire mode, how they should be -s is no problem, as it is just an additional block at top of picture but -l with its Row/Lut addrs at left will be screwed by -t or -f layouting leave -l away for -e, default "-l" becomes -q in effect, -s by option implemented short decoration for entire mode as viewentireheaderline() man page for libvirtex, was libvirtex.1 renamed to libvirtex.3, also in RCS changed Makefile to have proper install/uninstall, mkdir for man/man3 changed Makefile to for virtex.h (and later functions) do .so libvirtex.3 completed the previously only sketched out man page for libvirtex Makefile install/uninstall added loop that generates man pages with .so for virtex.h and all the functions and some of the variables in libvirtex.3 2002.10.08 Tue discussion about vendor tools, their faillures, mainly Xilinx, but also Altera http://neil.franklin.ch/Usenet/comp.arch.fpga/20021008_Why_can_Xilinx_sw_be_as_good_as_Altera_s_sw 2002.10.09 Wed and more vendor tool trouble, mainly Altera, but also Lattice http://neil.franklin.ch/Usenet/comp.arch.fpga/20021009_Why_can_t_Altera_sw_be_as_good_as_Xilinx_s_sw started writing an intro man page for the project, VirtexTools.7 while at it corrected some of the stuff in INSTALL, that was now outdated got some troff ideas from svgalib, improved style of existing 3 man pages put all URLs onto their onwn lines, with .br before them corrected/extended the "SEE ALSO" sections in all 3 existing man pages added VirtexTools.7 to Makefile install/uninstall/ci/tar, index.html.en corrected Makefile to also install/uninstall virtex.h 2002.10.10 Thu mentioned this project in the thread from 2002.10.08 above feedback shows that website does not say enough about how far I am nor about the planned further course (that is only in the todo: below) nor about the intended tool flow when the project is finished 2002.10.12 Sat as result of an feedback mail planned out work for further milestones 5 and 6 as result of later thinking also dod so for milestones 7 and 8 tidy up documentation to fit feedback requirements for more details Logfile todo:/index.html.en/README consistant ordering of vld and ved after vta Logfile todo: added fairly sure milestones 5/6 and possible 7/8 to todo: index.html.en merged implemented tools and intended tools to just intended added an entire further section on intended usage, tool flow with links to example vv and vd outputs of pdp10.bit updated example bitstream with links to above example output files upgraded project status to show what has been done up to now and what will be done in near future, as far as planned, up to milestone 8 added explicit names and links to the types of FPGAs to be supported added at top an index of page internal # links to sections FAQ improved/added Q&A about what is XAPP138, why am I doing this toolset what is better in this toolset than existing ones, why LUT-RAM/BRAM setter vd.1 und vv.1 added more info on options overriding others and previous self deleted reference to -n, as only sensible with editfile, use only in vm, pipe section "environment and config files" expanded to point to possibilities of using shell aliases or functions to set to preferences and then still be able to override them with command line arguments looked into vv -l outputting labels, are 3 char (only Col or Rol) = 3*(4+1)-1 so that gives max 14 pixels, and CLBs are shown as 48x18 or 48x72 or 24x36 so labels are always shorter, can fit as single line at top and left vv bug, -s should not show Sli/Lut, as range selection is only on Col/Row further bug found while fixing, in test for chopping length MaxChars not used is actually totally unneccessary variable, use strlen(Range) side effect first restrict range with '\0', then set '\\', also in non -e renamed viewentirelayoutedline() to viewentirelinelayouted() as result of an further feedback mail sketched out vas source code format what language should look like, label: I=