I could not route xi to the cpld. So I added solder points on the end to allow for clock in and out pins. You would have to route between them on your main board. Will be able to order with these pins in or out. Out it is direct replacement for prop.
How big of solder pads are needed for extra io? At 8mil via I can get a lot of pads in larger pads means less. Also is more double pins useful then more io? In multiplesof 4 what would be most useful prop pins to provide to double cpld
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Probably most useful is to make option to connect extra pins like I did for clocks. Will be difficult to run to far side of board but if I can will give 10 extra optional pins 8io + 2io/clock
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
dMajo said...
BTW: prop reset should go only to the cpld with a pulldown resistor and the cpld reset should instead to the dip40. if enough room a jumper between the two will be appreciated.
Wrong! I have discussed and clarified the thing with Chip. The prop RESn must be routed to the cpld and have a pull-up resistor (15K). An other cpld IO must be routed to the dip40 in place of the prop RESn. Between the two a jumper should exists (in case of unprogrammed/failed cpld). BOEn must be routed to cpld. When atcive (low) a brown-out condition occurs it is signalled throug a pull-down on the RESn. By routing the BOEn to the cpld, it can be aware of which mode the user have selected and react accordingly: if brown-out is detected the cpld can prepare itself again for prop boot (flash to eeprom emulation). Beside this if the user leaves BOEn floating it can be software driven by the cpld. Internal (software) reset cannot be detected through the RESn so the cpld will provide a reset comand (software subsitute). The prop internal (software) reset will became "shutdown": after it is issued the prop will attempt boot first from serial than from eeprom; because cpld will not be prepared for this the prop will enter shutdown till the next power/reset cycle. In power saving applications the cpld can drive reset after some time (user defined)·to weak-up the prop again (cold start - program executed from beginning) or hold/freeze the clock to the XIN (warm start - progam will execute from the exact point where it was stopped).
mctrivia said...
I could not route xi to the cpld. So I added solder points on the end to allow for clock in and out pins. You would have to route between them on your main board. Will be able to order with these pins in or out. Out it is direct replacement for prop.
How big of solder pads are needed for extra io? At 8mil via I can get a lot of pads in larger pads means less. Also is more double pins useful then more io? In multiples of 4 what would be most useful prop pins to provide to double cpld
I do not think that is a good idea having 80MHz going arround the pcb so much. It should go directly from the cpld to the prop's xin (shorter as possible). Even this is a direct replacement for the prop it the route between the cpld and the prop's xin is direct and short (taken from the outmost pin of the cpld and if possible not use the immediate cpld pins close to it).
The cpld can be initially programmed with that pin in HiZ and when the user wants to use the cpld provided clock can change it's settins (in the UFM and of course from one of the prop internal oscillator modes - it is supposed that such design will not have the crystal on the main board.)
Regarding the top/bottom IOs i think that 8+8 is more than enough. When I have asked you this the idea was to provide the opportunity·to connect a SD card holder/socket through a shielded or flat cable (usually in designs that have an enclosure it is pannel/pcb-side mounted. In case of pcb-side it will be on motherboard. With some modifications to the rokicki/lonesock low level driver it can be possible to access to the sd·through the parallel data bus gaining in speed.
Some users can use them just as IOs avoiding i2c expanders. During th weekend I had a thought also on multi-super-prop boards: those IOs can be used in a daisy-chain/token-ring fashion and deliver data at high speed. Only two manchester (cpld can handle this)·encoded lines (rx/tx) are enough. They can allow for prop-to-prop direct comunication but also prop-to-other_prop's_sram_DMA.
Regarding the double pins this is meant for set/reset req/ack communication using a single prop io pin (attached schematic).·Than have seen in the EPM handbook the BusHold feature. I am waiting an answer from a friend that has direct experience on the altera EPM family to clarify if it by BusHold I can obtain the same functionality. I need to know if it can be enabled/disabled on the fly based on user's request (my solution can be because is made with two pins). Than there is some issues on what happen to this pins during the cpls start-up: as I have understood they aren't HiZ so the user must pay attention on what is wired on them (with my solution the pins are HiZ during start-up). I really don't want lose this functionallity because you can really need it for backround tasks communications on single pin·(eg. you give a job to the cpld (state machine) and it will signal when done, you acknowledge and second_job/next_task starts·...)
Please hold on on this a little bit, as soon as I have al the infos/answers I will post them.
mctrivia said...
Exact same size as dip prop.
Probably most of the dip applications (already made), where you can consider this project as a prop direct replacement, are with sockets. If so no tall components are usually close to the prop top/bottom sides to facilitate the extraction. Considering this I see no problems if the board is a little longer than the dip prop (even mounted without socket) as long as it haven't components on the bottom layer in the excess area.
BTW: I am going to buy the MaxII Micro Kit so I can start porting what I have done from CoolRunnerII to the EPM
i agree running 80MHz should be done through short wide trace. However there is not room on the PCB for a properly sheilded trace. 80MHz unshielded could cause unexpected results. by running this way allows users to run a short trace on there main pcb if this feature is neaded. I beleive the difficulty in generating the required 160MHz will make it not used as often though. I will see if I can squeeze it in though.
You are correct about brown out will make appropriate change. I have widen the board about a 40th of an inch on each side to accommodate the adding of 10 extra optional pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
well i can't promise 16 io. the pin clips connect to both sides of pcb making seperate pads meaningless for them and I am pretty sure i can't get 10 extra traces to the oposite side of the board anyways(board is 90% routed)
i may be able to get 5 on far side+10 on near side but near side can only be used with 5 if you chose pins 10 if you solder to the pads direct.
finding a home for the jtag pins is also a fun process. i would prefer something where i don't need to solder anything on the board.
hope to have board design finished by wednesday so I can upload concept drawings and schematics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
mctrivia said...
i agree running 80MHz should be done through short wide trace. However there is not room on the PCB for a properly sheilded trace. 80MHz unshielded could cause unexpected results. by running this way allows users to run a short trace on there main pcb if this feature is neaded. I beleive the difficulty in generating the required 160MHz will make it not used as often though. I will see if I can squeeze it in though.
You are correct about brown out will make appropriate change. I have widen the board about a 40th of an inch on each side to accommodate the adding of 10 extra optional pins.
The clock trace (cpld-o to prop-xin)·should be short and thin (not wide). You can increase just a little bit the spacing between it and the adjacent ones. You can route one of the global clock inputs to prop-xout.
For the cpld clock 2 solutions:
- one of the attached (or similar) crystal oscillators connected to one of the globa cpld clock inputs (not the one connected to xout)
- two cpld io connected to a crystal 2 caps and resistor
No problem for the user due to 160M clock: it must be on-board !
there is no way i can get that crystal onto the board. it is almost the same size as the cpld and would leave no room for the voltage regulator or flash chip. I know 160MHz is high requency but it will have to go on the main board.
As for the clock signal between cpld and prop i can get a shielded 4mil trace on layer 3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Does anyone know if safe to connect nc pins to anything I like? I would think it means no connection to wafer. Would help in running some traces if I can connect to vcc or vss
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
I have not tested NC pins on a lot of chips, but every one I have checked with an ohmmeter (and reversing lead polarity) has been just what NC implies. No connection to anything on the chip even in the megohm and diode test range. Would suggest you test yours as well though.
i am pretty sure it will be fine. I have connected all but 6 of the nc pins to vss to allow for good routing of the ground plane to the actual vss pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
well i have not gotten as much done this week as i would like but other responsibilities have had to come first.
here is a pic of the top and bottom. not all traces are visible and pads along outside are not all visible but there will be 5 on each side.
going on trip with the wife for the weekend. hope to finish by mid next week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
here is a better view of top. gnd plane not shown to make more visible.
A is the cpld core enable jumper. when installed the extra pin to the left of it will control the cpld power supply. high or floating is on low is off.
B is the clock select jumper. when installed the cpld can drive the props xin.
unfortunately there is no room to install double pin resisters except on the far right side of the board so i may be able to do for prop p12-p15 internal space for traces will be the bigest limit of the ability to do this.
all the other 0603 parts are decoupling caps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
@mctrivia: for the double pins we can go without them but we need a small resistor between the prop and the cpld on pins P24..27 and P30..31
For the top/bottom side pads take care that you route at least one global clock on each side. Take care also on VCCio: if you want to keep open the opportunity to upgrade to 1270 you know that it have 4 io banks so 4 VCCio must be connected to 3.3V.
Regarding the pcb layout it seems ok but I have thought what about having cpld+ram on top and prop and flash on bottom? two reasons:1 security if you solder the daugterboard the prop/flash pins are not reachable so easy; 2) probably cpld+ram will consume more power than prop+flash (thermal consideration)
@jazzed: If I want to maximize the throughput vs. IO is correct that I can use a 9bit data bus(P0..8) when working in word mode? Is this code correct?
global setup here
.
.
.
AnyHub any hub op to get in sync (read command rdlong)
.
. 6 pasm instr to setup transaction with cpld
.
.
.
.
:Loop mov AddressH,AddressL
add AddressH,#2
movs Buffer,ina
modv Buffer,ina
wrword Buffer,AddressL
movs Buffer,ina
modv Buffer,ina
wrword Buffer,AddressH
add AddressL,#4
djnz LoopC,#:Loop
Can I say that every·48 prop system clocks I transfer a long from sram to hub (6.6MB/s sustained sequential transfer)? Can you correct me / elaborate some clever examples/ideas?
It will not be 48 clock cycles since the hub access goes out of the window you could have up to 22 wasted clock cycles per loop, but this makes sense assuming the CPLD puts the bits in the right place dddd_ddds_ssss_ssss .... would like to see your 6 setup codes.
If you stay in the window by placing extra hub access commands, you manage the precision and save 8 clock cycles over the broken window variation.
Assuming a single COG access driver, I think the best you could do with 8bit data and hub access would be this example (~6MB/s - overhead missing):
mov tp1, datp
mov tp2, datp
add tp2, #2
:rlp
waitpeq ack, ack ' 75ns - just to keep hub window - optionally wait for ACK
movs val1, ina ' 50ns xxxx_xxxx_xxxx_xxxx_xxxx_xxxa_AAAA_AAAA .
movd val1, ina ' 50ns xxxx_xxxx_xxxx_xx**_BBBB_BBBA_AAAA_AAAA .
wrlong val1, tp1 ' 75ns
movs val2, ina ' 50ns xxxx_xxxx_xxxx_xxxx_xxxx_xxxa_AAAA_AAAA .
movd val2, ina ' 50ns xxxx_xxxx_xxxx_xx**_BBBB_BBBA_AAAA_AAAA .
wrlong val2, tp2 ' 75ns
add tp1, #4 ' 50ns
add tp2, #4 ' 50ns
waitpeq ack, ack ' 75ns just to keep hub window
djnz len, #:rlp ' 50ns
Consider this burst routine with 16 bits address/data. It would give about 8MB/s max burst (command overhead missing).
'---------------------------------------------------
' rdbuf assumes 16 bit wide packet
' rdbuf packet mode is 0
'
' packet header:
' aaaa_aaaa - lower 16 bits of address ... Assert ATT bit (high)
' RCaa_aaaa - R = %1mmm (read command + mmm mode) C = %1xxx (attention bit)
' dont_care - allow for bus turn-around
' dddd_dddd - read from cpld for as long as ATT bit is set
' dont_care - Disassert ATT bit (low)
'
rdbuf
rdlong addr, adrp ' get address from user
mov outa, addr ' set lower 16 address
or addr, rdcmd ' set read and ATT command bit in packet header
shr addr, #16 ' position for packet
mov tp1, datp ' setup data pointer
mov tp2, datp ' setup data pointer
add tp2, #2 ' second data pointer offset (endianness adjust with access)
or outa, attn ' tell CPLD packet is starting
or dira, dbus ' 50ns to cpld - set dbus to output
mov outa, addr ' 50ns to cpld - send lower 16 bit address
andn dira, dbus ' 50ns cpld must wait
:rdlp waitpeq attn, attn ' 75ns keep hub access in window - can be used for ack if necessary
mov dlo, ina ' 50ns get low data
wrword dlo, tp1 ' 75ns from cpld - write data
add tp1, #4 ' 50ns increment data pointer
mov dhi, ina ' 50ns get low data
wrword dhi, tp2 ' 75ns from cpld - write data
add tp2, #4 ' 50ns increment data pointer
djnz len, #:rdlp ' 50ns jump if more to read
andn outa, attn ' 50ns tell CPLD we're done
jmp #cmdDone ' 21 instructions: overhead time + 250+225ns. burst rate approaches 8MB/s
For the most extreme single COG performance, you would need all 32 Propeller pins and a memory mapped bus architecture ... assuming one can switch to a special mode after boot (up to 10MB/s burst ... all overhead accounted for):
doCmd
rdlong cmd, cmdp ' 75
tjz cmd, #doCmd ' 50
rdlong len, lenp ' 75
mov dira, adrmask ' 50 set address
rdlong outa, adrp ' 75 get user address containing command and ATT bit
mov outa, len ' 50 send length to cpld
mov dira, #0 ' 50 set data mode
read32
rdlong data, tp ' 75 just to keep hub access in window
mov data, ina ' 50 get data
wrlong data, tp ' 75 write data
add tp, #4 ' 50 incr pointer
djnz len, #read32 ' 75 jump
cmdDone
wrlong dirb, cmdp ' 75
jmp #doCmd ' 50
I have routed all 12 vcio pins for max flexibility and stability.
I have managed to get 4 double pins to the outside extra 10 pins
What is the purpose of small resisters on those pins? Space is very tight on upper pin counts. Middle pins p12-p19 are easy to put resisters on.
If absolutely essential I can move things around to get resisters on that side but would be lot of work. I have 150r and 10k in stock.
Reason for prop on top is to make routing of pins easier since pin order is same as package.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
@mctrivia: Regarding the double pins this is meant for set/reset req/ack communication using a single prop io pin (attached schematic). This allows set/reset comm on single pin (eg. cpld outputs a state to the prop through a resistor, when prop perform the required action output the opposite state on the same pin that before was an input, cpld know this because on the directly connected pin reads the opposite state as on the other one going through the resistor).
By using the cpls bus-hold feature you do not need two pins on cpld but you still need the resisto (150R OK) to prevent shorts (damage) if the prop is driving the pin at the same time the cpld is outputind opposite level.
The use of P24..31 (except P28..29 = i2c = 4k7 pull-up) was due to easy handling through pasm instructions (thanks jazzed)
@jazzed: I thought hub op is min 87.5ns (7*12.5). Even this way I cannot understand where my code is wrong. BTW: Why have you used wrlong instead of wrword in your first example?
global setup here
.
.
.
-----------------------------------------------
rdlong ' 75ns <any hub op to get in sync (read command rdlong)
. 6 pasm instr ' 50ns
. to setup ' 50ns
--------------- transaction --------
. ' 50ns
. ' 50ns
. ' 50ns
. ' 50ns
-----------------------------------------------
:Loop mov AddressH, AddressL ' 50ns / if wrword here: when back from djnz will meet the hub
add AddressH, #2 ' 50ns \ this and previous pasm line replaces wrword
movs Buffer, ina ' 50ns / here again the usual 2 pasm after virtual wrword (previous lines)
movd Buffer, ina ' 50ns \
-----------------------------------------------
wrword Buffer, AddressL ' 75ns (so here again ok)
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressH ' 75ns
add AddressL, #4 ' 50ns
djnz LoopC, #:Loop ' 50ns
----------------------------------------------- ' 50ns (when go through djnz)
pasm ' 50ns
Can you show me where the error is so that I can understand better the timings? From the datasheet/manual I have uderstood that the hub window is every 16 clocks (so 200ns) isn't it? ".... would like to see your 6 setup codes." Me also ... ... Ok if no 6 then there is space for 10 till the next window. But I will go on this after I have clarified the bottom asertion
BTW: Perhaps I have found a way to keep in sync the vga video mode and the hub window once forever (You setup the sync and then until the cog is running no need to resync - I hope). I need to elaborate still a little bit then I will ask your opinion. If it works it will open many doors.
BTW: If someone has already done it, I don't want to reinvent the "hot water" (where is it?)
ok i will make apropriate changes [noparse]:([/noparse] will take several hours.
by the way should i tie the reset to the clrn pin and leave oe floating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
@dMajo, the wrlong in the first code block should be wrword ... my mistake. You're right about 7 clock cycles minimum for hub operations ... unfortunately the maximum number of cycles is 22. The problem is we only get 2 instructions (up to 8 cycles) between hub operations before the tight timing window is broken. Most instructions take 4 cycles. This is where your code has trouble. If you could replace those 2 instructions a the top of :loop, it's fine, but I don't see how to do that because you have to advance both pointers for it to work (lack of indexed addressing is pretty absurd no?).
BTW: I think this is way to get a 2 COG 8MB/s loop going. Using 5 COGs, 4x the one COG rate would be possible. But nothing would be left for applications :<
i am going to have to build a programing rig for these things. for testing and 1 offs soldering to the pads will work though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
@Jazzed: Sorry for my blind ignorance, but still I cannot focus the problem, I am unable to see the error lines: "It will not be 48 clock cycles since the hub access goes out of the window you could have up to 22 wasted clock cycles per loop ..."··· Where? "... You're right about 7 clock cycles minimum for hub operations ... unfortunately the maximum number of cycles is 22. The problem is we only get 2 instructions (up to 8 cycles) between hub operations before the tight timing window is broken. Most instructions take 4 cycles. This is where your code has trouble. ..."···· Where, in which line?
I assume this loop is correct (consider only while looping): every 48 clocks (600ns) it transfers 3 words=========================================================================================================
:Loop wrword ANY, ANY ' 75ns
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressL ' 75ns
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressH ' 75ns
add AddressL, #4 ' 50ns
djnz LoopC, #:Loop ' 50ns
If the above is correct, than, in the below code I have exchanged a hub op with 2 pasm instructions.
I should meet the window: Is this loop transfering 2 words every 48 ticks (600ns)?
===========================================================================================================
:Loop mov AddressH, AddressL ' 50ns / if wrword here: when back from djnz will meet the hub
add AddressH, #2 ' 50ns \ this and previous pasm line replaces wrword
movs Buffer, ina ' 50ns / here again the usual 2 pasm after virtual wrword (previous lines)
movd Buffer, ina ' 50ns \
-----------------------------------------------
wrword Buffer, AddressL ' 75ns (so here again ok)
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressH ' 75ns
add AddressL, #4 ' 50ns
djnz LoopC, #:Loop ' 50ns
·As I understand I have 16 clocks between the hub windows. If I have a synced hub op then I take 7 clocks for the hub acces and 9 clocks remains for pasm code. If I want access every second window the hub then I have 16 clean clocks for pasm more eg: 16pasm + 7hub + 9pasm + 16pasm + 7hub + 9pasm ... or like in my case 16pasm+7hub+9pasm+7hub+9pasm+16pasm+7hub+9pasm ...
Where is the error? I really cannot see it. Am I missing some docs/infos somewhere?
I assume this loop is correct (consider only while looping): every 48 clocks (600ns) it transfers 3 words
=========================================================================================================
:Loop wrword ANY, ANY ' 75ns
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressL ' 75ns
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressH ' 75ns
add AddressL, #4 ' 50ns <-- you advance the AddressL pointer only ....
djnz LoopC, #:Loop ' 50ns
If you do not advance the AddressH pointer, it does not work.
You need a hub instruction every 3 PASM lines to stay in the window.
===========================================================================================================
wrword Buffer, AddressL ' 75ns ... some hub instruction here only for "first-time" illustration.
:Loop mov AddressH, AddressL ' 50ns ... in window the first time - missing window on loop
add AddressH, #2 ' 50ns ... in window the first time - out of window on loop
movs Buffer, ina ' 50ns ... missing window first time- out of window on loop
movd Buffer, ina ' 50ns ... always out of window
-----------------------------------------------
wrword Buffer, AddressL ' 75ns ... not ok in any case. broken window ... takes up to 22 cycles to finish.
movs Buffer, ina ' 50ns ... ok, still in hub window
movd Buffer, ina ' 50ns ... ok, still in hub window
-----------------------------------------------
wrword Buffer, AddressH ' 75ns ... ok, still in hub window and it's a hub instruction so we get 2 more
add AddressL, #4 ' 50ns ... ok, still in hub window
djnz LoopC, #:Loop ' 50ns ... ok, still in hub window
@jazzed: OK my fault: please don't care the address pointers of the first example (I knew they were wrong, the purpose was only to show you the timings and to explain better due to my bad english), consider only the hub window meeting. It meets the timings or not? (The 3 wrword will stay in window during looping? - dont't look at 4clock pasm code, just the window timing)
Here you have a reworked second example based upon your first line addition. Could you make the same anlyses over this?
===========================================================================================================
rdlong Address, HubPoint ' 75ns ... some hub instruction here only for "first-time" illustration
mov AddressL, Address ' 50ns ... some pasm instruction here only for "first-time" illustration
mov LoopC, #100 ' 50ns ... some pasm instruction here only for "first-time" illustration
-----------------------------------------------
:Loop mov AddressH, AddressL ' 50ns / this two pasm lines replaces or not a single hub-op line ???
add AddressH, #2 ' 50ns \
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressL ' 75ns
movs Buffer, ina ' 50ns
movd Buffer, ina ' 50ns
-----------------------------------------------
wrword Buffer, AddressH ' 75ns
add AddressL, #4 ' 50ns
djnz LoopC, #:Loop ' 50ns
Does this loop have or not a long transferred in 48 clocks, one non used window followed by two word-transfer windows ? Where the error if any? Having a hub-op followed by 2 pasms is the same as 4 pasms or not?
NetHog said...
So, any room for another feature? (Quickly bolts for the nearest exit)
The board is pretty tight but i will try to squeeze it in if can. what is your request?
one addition i have made is optional pins use. The extra pins are
1-40 are same as prop
30 can be CPLD clock out with a jumper.
A,B,C,D have direct connection to cpld pins on bottom
B,C are cpld clock in on bottom
A,B,C,D have connection to cpld pins through a 150R on top
E is jumper selectable between cpld pin, 3.3V, or power on/off
F,G,H,J are connected to CPLD through 150R resister
K is jumper selectable between gnd and cpld pin.
obviously using pins shorts top and bottom so if using pins A,B,C,D become physical double pin setup if not you have up to 15 extra io available.
i have done this arrangement so if lettered pins are mounted up a 16MB expansion board could be mounted on them and still be pin compatible with prop or if mounted down you get 8-10 extra io lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
mctrivia said...
ok i will make apropriate changes [noparse]:([/noparse] will take several hours.
by the way should i tie the reset to the clrn pin and leave oe floating.
To resume:
==========
Yes the DEV_CLRn should go to the DIP40-pin11 and another CLPD-IO should go to the Prop-pin7(RESn): between the two you should have a small jumper.
The DEV_OE should go to one of the top/bottom side pads (could be left floating)
One of the GCLK[noparse][[/noparse]0..3] should go to the Prop-XO, one to the Prop-XI (JP_CLK) and the other two should go to the top/bottom side pads (one per side)
One CPLD-IO should go through a jumper(JP_CLK)·to Prop-XI
PropXI CPLD_GCLK[noparse][[/noparse]0..3] Case 1 Case 2
| |
JP_CLK -----> o o o o o--o o--o o o--o o
| |
CPLD_IO DIP40pin30
One CPLD-IO should go to Prop-pin6(BOEn).
For Prop(P24..31) pins you should have a 150R between the prop and cpld. P28..29 should have pull-up resistors (10K) on the prop side. Connections to DIP40 header should be·on the Prop pins (side)
All VCCIO[noparse][[/noparse]1..4] and GNDIO (refer to EPM1270 pin-out) should be connected
Winbond flash have 6 IOs to the CPLD. (Packages |8-pad-WSON-8x6mm|16-pin-SOIC-300mil| fits from W25Q16BV to W25Q128BV)
It will be nice if you can use for P0..15 the IO from bank3(EPM1270) that overlaps with the ones of bank2(EPM570). The same for the remaining top/bottom side pads
Please follow also Sapieha considerations regarding the Prop decoupling capacitors.
EPMx have a built-in core voltage regulator. For G models you need to provide regulated 1.8V. The max power estimation for a 1270 device running @200MHz is ~785mW without IO load (very small in this application-just the input leakage of the ICs connected to the cpld).
If you assume a well regulated 3.3V you can provide the 1.8V through a voltage drop over rectifier diodes [noparse][[/noparse]3.3V-2(0.7V)=1.9V] or a small rectifier bridge in series (VCCto-, VCCINTto+, ~floating). Efficiency is the same (higher) as with a linear regulator but requires a good-stable (better?) 3.3V
3.3V should be well regulated but i have know control of that. voltage regulators tend to be smaller then 2 diodes and would be more stable with regulator. one i am using is only 200mA wich is more then the average but way less then the max you quoted will see if i can find a 500-600mA it is usually ok to under power temporarily.
570 and 1270 have same power pads so no wories there.
trying to tie any particular traces to any particular bank in this small of a package has proven to be impossible for ram traces. i may be able to keep prop pins to a specific bank. how much of a hit will we take not keeping to any particular bank?
all routes but xo have been made. as mentioned above. what need is there for xo? can we not either run the prop xin from cpld or have prop run the cpld clock? i have tied the clock pins as follows
B,C,30
i have one unrouted and can connect to any of the following pads 1-20
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
also is max power estimate core only? only the core current effects size of regulator.
there is plenty of decoupling caps on the board. i am using all ceramic caps but will should meet the requirements to overclock.
2 decoupling caps will be needed off board just like you would for a regular prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Please read the following line carefully: You need a hub instruction every 3 PASM lines (or less) to stay in the window.
That's the way it works ... we have no choice unless we use another CPU.
I have understood this concept. But as I understand the datasheet the hub is running synchronous (half the speed but with same system clock) with the cog so once get in sync this can be kept forever
' COG keeps in the window
'
rdlong val1, ptr / ' wait up to 22 cycles to get hub access: from now in sync
mov val2, val1 |
add ptr, #4 \_
rdlong val1, ptr / ' in sync
mov val2, val1 |
mov val2, val1 \_
rdlong val1, ptr / ' in sync
mov val2, val1 |
mov val2, val1 \_
add ptr, #4 / ' hub window is passing but cog have nothing to do with it
mov val2, val1 |
mov val2, val1 |
mov val2, val1 \_
rdlong val1, ptr / ' next pass: COG STILL in sync
mov val2, val1 |
mov val2, val1 \_
...
For the last time (I promise··) is the above true ?
mctrivia said...
also is max power estimate core only? only the core current effects size of regulator.
there is plenty of decoupling caps on the board. i am using all ceramic caps but will should meet the requirements to overclock.
2 decoupling caps will be needed off board just like you would for a regular prop.
1) yes, so IO load have nothing to do with it (my fault)
3) beside the usual .1uF close to every VCC pin I will be happy to see also one 20/25uF6V on the 3.3V onboard rail (like a hub - star center) between the dip power supply and each onboard VCC pin: ··· something like this or this
Comments
How big of solder pads are needed for extra io? At 8mil via I can get a lot of pads in larger pads means less. Also is more double pins useful then more io? In multiplesof 4 what would be most useful prop pins to provide to double cpld
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
The cpld can be initially programmed with that pin in HiZ and when the user wants to use the cpld provided clock can change it's settins (in the UFM and of course from one of the prop internal oscillator modes - it is supposed that such design will not have the crystal on the main board.)
Regarding the top/bottom IOs i think that 8+8 is more than enough. When I have asked you this the idea was to provide the opportunity·to connect a SD card holder/socket through a shielded or flat cable (usually in designs that have an enclosure it is pannel/pcb-side mounted. In case of pcb-side it will be on motherboard. With some modifications to the rokicki/lonesock low level driver it can be possible to access to the sd·through the parallel data bus gaining in speed.
Some users can use them just as IOs avoiding i2c expanders. During th weekend I had a thought also on multi-super-prop boards: those IOs can be used in a daisy-chain/token-ring fashion and deliver data at high speed. Only two manchester (cpld can handle this)·encoded lines (rx/tx) are enough. They can allow for prop-to-prop direct comunication but also prop-to-other_prop's_sram_DMA.
Regarding the double pins this is meant for set/reset req/ack communication using a single prop io pin (attached schematic).·Than have seen in the EPM handbook the BusHold feature. I am waiting an answer from a friend that has direct experience on the altera EPM family to clarify if it by BusHold I can obtain the same functionality. I need to know if it can be enabled/disabled on the fly based on user's request (my solution can be because is made with two pins). Than there is some issues on what happen to this pins during the cpls start-up: as I have understood they aren't HiZ so the user must pay attention on what is wired on them (with my solution the pins are HiZ during start-up). I really don't want lose this functionallity because you can really need it for backround tasks communications on single pin·(eg. you give a job to the cpld (state machine) and it will signal when done, you acknowledge and second_job/next_task starts·...)
Please hold on on this a little bit, as soon as I have al the infos/answers I will post them. Probably most of the dip applications (already made), where you can consider this project as a prop direct replacement, are with sockets. If so no tall components are usually close to the prop top/bottom sides to facilitate the extraction. Considering this I see no problems if the board is a little longer than the dip prop (even mounted without socket) as long as it haven't components on the bottom layer in the excess area.
BTW: I am going to buy the MaxII Micro Kit so I can start porting what I have done from CoolRunnerII to the EPM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
You are correct about brown out will make appropriate change. I have widen the board about a 40th of an inch on each side to accommodate the adding of 10 extra optional pins.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
i may be able to get 5 on far side+10 on near side but near side can only be used with 5 if you chose pins 10 if you solder to the pads direct.
finding a home for the jtag pins is also a fun process. i would prefer something where i don't need to solder anything on the board.
hope to have board design finished by wednesday so I can upload concept drawings and schematics.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
For the cpld clock 2 solutions:
- one of the attached (or similar) crystal oscillators connected to one of the globa cpld clock inputs (not the one connected to xout)
- two cpld io connected to a crystal 2 caps and resistor
No problem for the user due to 160M clock: it must be on-board !
File Attachment :
MCSOHVT.pdf·· 72KB (application/pdf)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
As for the clock signal between cpld and prop i can get a shielded 4mil trace on layer 3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
here is a pic of the top and bottom. not all traces are visible and pads along outside are not all visible but there will be 5 on each side.
going on trip with the wife for the weekend. hope to finish by mid next week.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
A is the cpld core enable jumper. when installed the extra pin to the left of it will control the cpld power supply. high or floating is on low is off.
B is the clock select jumper. when installed the cpld can drive the props xin.
unfortunately there is no room to install double pin resisters except on the far right side of the board so i may be able to do for prop p12-p15 internal space for traces will be the bigest limit of the ability to do this.
all the other 0603 parts are decoupling caps.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Post Edited (mctrivia) : 9/3/2009 8:38:49 AM GMT
For the top/bottom side pads take care that you route at least one global clock on each side. Take care also on VCCio: if you want to keep open the opportunity to upgrade to 1270 you know that it have 4 io banks so 4 VCCio must be connected to 3.3V.
Regarding the pcb layout it seems ok but I have thought what about having cpld+ram on top and prop and flash on bottom? two reasons:1 security if you solder the daugterboard the prop/flash pins are not reachable so easy; 2) probably cpld+ram will consume more power than prop+flash (thermal consideration)
@jazzed: If I want to maximize the throughput vs. IO is correct that I can use a 9bit data bus(P0..8) when working in word mode? Is this code correct?
global setup here . . . AnyHub any hub op to get in sync (read command rdlong) . . 6 pasm instr to setup transaction with cpld . . . . :Loop mov AddressH,AddressL add AddressH,#2 movs Buffer,ina modv Buffer,ina wrword Buffer,AddressL movs Buffer,ina modv Buffer,ina wrword Buffer,AddressH add AddressL,#4 djnz LoopC,#:LoopCan I say that every·48 prop system clocks I transfer a long from sram to hub (6.6MB/s sustained sequential transfer)? Can you correct me / elaborate some clever examples/ideas?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
If you stay in the window by placing extra hub access commands, you manage the precision and save 8 clock cycles over the broken window variation.
Assuming a single COG access driver, I think the best you could do with 8bit data and hub access would be this example (~6MB/s - overhead missing):
Consider this burst routine with 16 bits address/data. It would give about 8MB/s max burst (command overhead missing).
For the most extreme single COG performance, you would need all 32 Propeller pins and a memory mapped bus architecture ... assuming one can switch to a special mode after boot (up to 10MB/s burst ... all overhead accounted for):
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/5/2009 10:11:32 PM GMTI have managed to get 4 double pins to the outside extra 10 pins
What is the purpose of small resisters on those pins? Space is very tight on upper pin counts. Middle pins p12-p19 are easy to put resisters on.
If absolutely essential I can move things around to get resisters on that side but would be lot of work. I have 150r and 10k in stock.
Reason for prop on top is to make routing of pins easier since pin order is same as package.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
By using the cpls bus-hold feature you do not need two pins on cpld but you still need the resisto (150R OK) to prevent shorts (damage) if the prop is driving the pin at the same time the cpld is outputind opposite level.
The use of P24..31 (except P28..29 = i2c = 4k7 pull-up) was due to easy handling through pasm instructions (thanks jazzed)
@jazzed: I thought hub op is min 87.5ns (7*12.5). Even this way I cannot understand where my code is wrong. BTW: Why have you used wrlong instead of wrword in your first example?
global setup here . . . ----------------------------------------------- rdlong ' 75ns <any hub op to get in sync (read command rdlong) . 6 pasm instr ' 50ns . to setup ' 50ns --------------- transaction -------- . ' 50ns . ' 50ns . ' 50ns . ' 50ns ----------------------------------------------- :Loop mov AddressH, AddressL ' 50ns / if wrword here: when back from djnz will meet the hub add AddressH, #2 ' 50ns \ this and previous pasm line replaces wrword movs Buffer, ina ' 50ns / here again the usual 2 pasm after virtual wrword (previous lines) movd Buffer, ina ' 50ns \ ----------------------------------------------- wrword Buffer, AddressL ' 75ns (so here again ok) movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressH ' 75ns add AddressL, #4 ' 50ns djnz LoopC, #:Loop ' 50ns ----------------------------------------------- ' 50ns (when go through djnz) pasm ' 50nsCan you show me where the error is so that I can understand better the timings? From the datasheet/manual I have uderstood that the hub window is every 16 clocks (so 200ns) isn't it?
".... would like to see your 6 setup codes." Me also ...
BTW: Perhaps I have found a way to keep in sync the vga video mode and the hub window once forever (You setup the sync and then until the cog is running no need to resync - I hope). I need to elaborate still a little bit then I will ask your opinion. If it works it will open many doors.
BTW: If someone has already done it, I don't want to reinvent the "hot water" (where is it?)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
by the way should i tie the reset to the clrn pin and leave oe floating.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
BTW: I think this is way to get a 2 COG 8MB/s loop going. Using 5 COGs, 4x the one COG rate would be possible. But nothing would be left for applications :<
' COG1 wrword zero, SyncPtr wrword HubAdr, AddressPtr :Loop rdlong Sync, SyncPtr add HubAdr, #2 wrword HubAdr, AddressPtr djnz len, :Loop ' COG2 :syncup rdword Sync, SyncPtr tjz Sync, #:syncup :Loop rdlong HubAdr, AddressPtr ' 75ns mov Buffer, ina ' 50ns wrword Buffer, HubAdr ' 75ns djnz LoopC, #:Loop ' 50ns▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
- Propalyzer: Propeller PC Logic Analyzer
- BMA: An on-chip PASM Debugger
- SPUD: Spin Source Level Debugger
Post Edited (jazzed) : 9/8/2009 6:33:59 AM GMT▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
"It will not be 48 clock cycles since the hub access goes out of the window you could have up to 22 wasted clock cycles per loop ..."··· Where?
"... You're right about 7 clock cycles minimum for hub operations ... unfortunately the maximum number of cycles is 22. The problem is we only get 2 instructions (up to 8 cycles) between hub operations before the tight timing window is broken. Most instructions take 4 cycles. This is where your code has trouble. ..."···· Where, in which line?
I assume this loop is correct (consider only while looping): every 48 clocks (600ns) it transfers 3 words========================================================================================================= :Loop wrword ANY, ANY ' 75ns movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressL ' 75ns movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressH ' 75ns add AddressL, #4 ' 50ns djnz LoopC, #:Loop ' 50ns If the above is correct, than, in the below code I have exchanged a hub op with 2 pasm instructions. I should meet the window: Is this loop transfering 2 words every 48 ticks (600ns)? =========================================================================================================== :Loop mov AddressH, AddressL ' 50ns / if wrword here: when back from djnz will meet the hub add AddressH, #2 ' 50ns \ this and previous pasm line replaces wrword movs Buffer, ina ' 50ns / here again the usual 2 pasm after virtual wrword (previous lines) movd Buffer, ina ' 50ns \ ----------------------------------------------- wrword Buffer, AddressL ' 75ns (so here again ok) movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressH ' 75ns add AddressL, #4 ' 50ns djnz LoopC, #:Loop ' 50ns·As I understand I have 16 clocks between the hub windows. If I have a synced hub op then I take 7 clocks for the hub acces and 9 clocks remains for pasm code. If I want access every second window the hub then I have 16 clean clocks for pasm more eg: 16pasm + 7hub + 9pasm + 16pasm + 7hub + 9pasm ... or like in my case 16pasm+7hub+9pasm+7hub+9pasm+16pasm+7hub+9pasm ...
Where is the error? I really cannot see it. Am I missing some docs/infos somewhere?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
I assume this loop is correct (consider only while looping): every 48 clocks (600ns) it transfers 3 words ========================================================================================================= :Loop wrword ANY, ANY ' 75ns movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressL ' 75ns movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressH ' 75ns add AddressL, #4 ' 50ns <-- you advance the AddressL pointer only .... djnz LoopC, #:Loop ' 50nsIf you do not advance the AddressH pointer, it does not work.
You need a hub instruction every 3 PASM lines to stay in the window. =========================================================================================================== wrword Buffer, AddressL ' 75ns ... some hub instruction here only for "first-time" illustration. :Loop mov AddressH, AddressL ' 50ns ... in window the first time - missing window on loop add AddressH, #2 ' 50ns ... in window the first time - out of window on loop movs Buffer, ina ' 50ns ... missing window first time- out of window on loop movd Buffer, ina ' 50ns ... always out of window ----------------------------------------------- wrword Buffer, AddressL ' 75ns ... not ok in any case. broken window ... takes up to 22 cycles to finish. movs Buffer, ina ' 50ns ... ok, still in hub window movd Buffer, ina ' 50ns ... ok, still in hub window ----------------------------------------------- wrword Buffer, AddressH ' 75ns ... ok, still in hub window and it's a hub instruction so we get 2 more add AddressL, #4 ' 50ns ... ok, still in hub window djnz LoopC, #:Loop ' 50ns ... ok, still in hub window▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
Here you have a reworked second example based upon your first line addition. Could you make the same anlyses over this?
=========================================================================================================== rdlong Address, HubPoint ' 75ns ... some hub instruction here only for "first-time" illustration mov AddressL, Address ' 50ns ... some pasm instruction here only for "first-time" illustration mov LoopC, #100 ' 50ns ... some pasm instruction here only for "first-time" illustration ----------------------------------------------- :Loop mov AddressH, AddressL ' 50ns / this two pasm lines replaces or not a single hub-op line ??? add AddressH, #2 ' 50ns \ movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressL ' 75ns movs Buffer, ina ' 50ns movd Buffer, ina ' 50ns ----------------------------------------------- wrword Buffer, AddressH ' 75ns add AddressL, #4 ' 50ns djnz LoopC, #:Loop ' 50nsDoes this loop have or not a long transferred in 48 clocks, one non used window followed by two word-transfer windows ? Where the error if any? Having a hub-op followed by 2 pasms is the same as 4 pasms or not?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
one addition i have made is optional pins use. The extra pins are
1-40 are same as prop
30 can be CPLD clock out with a jumper.
A,B,C,D have direct connection to cpld pins on bottom
B,C are cpld clock in on bottom
A,B,C,D have connection to cpld pins through a 150R on top
E is jumper selectable between cpld pin, 3.3V, or power on/off
F,G,H,J are connected to CPLD through 150R resister
K is jumper selectable between gnd and cpld pin.
obviously using pins shorts top and bottom so if using pins A,B,C,D become physical double pin setup if not you have up to 15 extra io available.
i have done this arrangement so if lettered pins are mounted up a 16MB expansion board could be mounted on them and still be pin compatible with prop or if mounted down you get 8-10 extra io lines.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
Please read the following line carefully:
You need a hub instruction every 3 PASM lines (or less) to stay in the window.
That's the way it works ... we have no choice unless we use another CPU.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propeller Tools
==========
Yes the DEV_CLRn should go to the DIP40-pin11 and another CLPD-IO should go to the Prop-pin7(RESn): between the two you should have a small jumper.
The DEV_OE should go to one of the top/bottom side pads (could be left floating)
One of the GCLK[noparse][[/noparse]0..3] should go to the Prop-XO, one to the Prop-XI (JP_CLK) and the other two should go to the top/bottom side pads (one per side)
One CPLD-IO should go through a jumper(JP_CLK)·to Prop-XI
PropXI CPLD_GCLK[noparse][[/noparse]0..3] Case 1 Case 2 | | JP_CLK -----> o o o o o--o o--o o o--o o | | CPLD_IO DIP40pin30One CPLD-IO should go to Prop-pin6(BOEn).
For Prop(P24..31) pins you should have a 150R between the prop and cpld. P28..29 should have pull-up resistors (10K) on the prop side. Connections to DIP40 header should be·on the Prop pins (side)
All VCCIO[noparse][[/noparse]1..4] and GNDIO (refer to EPM1270 pin-out) should be connected
Winbond flash have 6 IOs to the CPLD. (Packages |8-pad-WSON-8x6mm|16-pin-SOIC-300mil| fits from W25Q16BV to W25Q128BV)
It will be nice if you can use for P0..15 the IO from bank3(EPM1270) that overlaps with the ones of bank2(EPM570). The same for the remaining top/bottom side pads
Please follow also Sapieha considerations regarding the Prop decoupling capacitors.
EPMx have a built-in core voltage regulator. For G models you need to provide regulated 1.8V. The max power estimation for a 1270 device running @200MHz is ~785mW without IO load (very small in this application-just the input leakage of the ICs connected to the cpld).
If you assume a well regulated 3.3V you can provide the 1.8V through a voltage drop over rectifier diodes [noparse][[/noparse]3.3V-2(0.7V)=1.9V] or a small rectifier bridge in series (VCCto-, VCCINTto+, ~floating). Efficiency is the same (higher) as with a linear regulator but requires a good-stable (better?) 3.3V
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
570 and 1270 have same power pads so no wories there.
trying to tie any particular traces to any particular bank in this small of a package has proven to be impossible for ram traces. i may be able to keep prop pins to a specific bank. how much of a hit will we take not keeping to any particular bank?
all routes but xo have been made. as mentioned above. what need is there for xo? can we not either run the prop xin from cpld or have prop run the cpld clock? i have tied the clock pins as follows
B,C,30
i have one unrouted and can connect to any of the following pads 1-20
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
there is plenty of decoupling caps on the board. i am using all ceramic caps but will should meet the requirements to overclock.
2 decoupling caps will be needed off board just like you would for a regular prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
propmod_us and propmod_1x1 are in stock. Only $30. PCB available for $5
Want to make projects and have Gadget Gangster sell them for you? propmod-us_ps_sd and propmod-1x1 are now available for use in your Gadget Gangster Projects.
Need to upload large images or movies for use in the forum. you can do so at uploader.propmodule.com for free.
For the last time (I promise·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)
3) beside the usual .1uF close to every VCC pin I will be happy to see also one 20/25uF6V on the 3.3V onboard rail (like a hub - star center) between the dip power supply and each onboard VCC pin:
··· something like this or this
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates)