ZEROX Zero extends D above bit S[4:0].
Basically Chip is doing a single instruction AND dirb,##3fffffff
Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.
ZEROX Zero extends D above bit S[4:0].
Basically Chip is doing a single instruction AND dirb,##3fffffff
Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.
But zerox clears all bits after the specified bit and does not include the bit itself so therefore an operand of #30 means only the top bit is cleared so it is a ##7FFFFFFF.
This is borne out by this test.
TAQOZ# -1 3 ZEROX .LONG 0000.000F ok
TAQOZ# -1 30 ZEROX .LONG 7FFF.FFFF ok
ZEROX Zero extends D above bit S[4:0].
Basically Chip is doing a single instruction AND dirb,##3fffffff
Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.
But zerox clears all bits after the specified bit and does not include the bit itself so therefore an operand of #30 means only the top bit is cleared so it is a ##7FFFFFFF.
This is borne out by this test.
TAQOZ# -1 3 ZEROX .LONG 0000.000F ok
TAQOZ# -1 30 ZEROX .LONG 7FFF.FFFF ok
I should have used #29, then. I'm glad you found this.
reset_pins setint1 #0 'disable int1
mov dira,#0 'reset smart pins (avoids output on mode clears)
zerox dirb,#29 'clear rx & tx (P62-63) Others??? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
'decod dirb,#(tx_pin-32) <<<<<<<<<<<<<<<<<<<<< BUT THIS MAKES MORE SENSE (pbj)
wrpin #0,#rx_ths 'clear rx_ths mode
wrpin #0,#rx_tne 'clear rx_tne mode
wrpin #0,#rx_pin 'clear rx_pin mode
_ret_ wrpin #0,#tx_pin 'clear tx_pin mode
lut_end
It seems to both Peter and I that since all pins P00-P31 are cleared with the MOV DIRA,#0 that you would also be clearing at least all pins P32-P61. Whether in fact you also want to clear P62-P63 is unclear to us.
I made a variation of Chip's instruction spreadsheet that breaks out instructions into multiple sheets (by group), sorts on the instruction name, and hides some of the columns. I've found this particularly useful for reading on my mobile devices. Here's the link, in case anyone else might find it useful:
I made a variation of Chip's instruction spreadsheet that breaks out instructions into multiple sheets (by group), sorts on the instruction name, and hides some of the columns. I've found this particularly useful for reading on my mobile devices. Here's the link, in case anyone else might find it useful:
Chip,
The FPGA code is too big for our forum. Could you please post it thanks.
All,
For those with BeMicroCV-A9 boards...
Here is the latest code v134a as follows (uses BeMicro_A9_Prop2_8cogs_v32d.jic)...
Chip's latest ROM_Booter v33d with the special new ROM section commented out
Peter's TAQOZ BOOTROM(7) from dropbox BOOTROM.spin2 12/5/2018 23:41 using reset_pins instead of inline at start
Ray's SD boot code SD2_133jx/ROM_133k
Ray's Monitor code LSD_v133i/ROM_133k
I have checked out the serial, monitor and taqoz without using pullups. SD and Flash not tested yet.
Pins P58..P61 are for connections to Flash (4-pin only) and/or SD card. There is no internal FPGA connections on these pins and they are NOT connected to the on-board SD card!!
P63 Rxd
P62 Txd
P61 spi-CS sd-CK pu = spi flash
P60 spi-CK sd-CS pu = SD card (pullup is internal on the card)
P59 spi-DI sd-DI pu = Serial pd = Stop
P58 spi-DO sd-DO
Here is the boot sequence...
P59 pullup = goto Serial
P60 pullup = goto SD card
P61 pullup = goto SPI Flash
P59 pulldn = Stop
else = goto Serial
Please test this out urgently as this is scheduled to go to OnSemi on Monday!!!
Don't forget to program the new fpga code into your BeMicro A9 board.
To enter TAQOZ from Serial, type "> " without quotes to autobaud the serial code, then "Prop_TAQ" or for the monitor "Prop_MON".
From the monitor enter <esc><cr> to goto TAQOZ.
For instructions/commands see the relevant thread.
For SD, copy a binary file named "_P2_BOOT.BIX" or "_P2_BOOT.BIY" to the card. I posted a simple file in the SD Boot thread.
I thought I would pass this info on as I found it fascinating. Hope I get it right.
Chip said that the testing involves a mass of gates which serialise all the outputs from all flops in the chip. This accounts for ~15% of the gates on the die!!! It also impacts the ultimate chip speed as it is also a gating factor
OnSemi also does full testing on every bit of RAM with rolling patterns.
It's all controlled by software far removed from the real silicon. When the software passes, the chip is pretty much guaranteed to work!
IIRC there were 22 processes to make the 350nm P1. There will be 100+ for the 280nm P2. And a process may contain a number of exposures of different masks to create one layer.
And this is a smallish chip on an old generation process. Imagine what goes into making a Xenon CPU or Apple A10 CPU !!!
Chip, would it be possible to get an FPGA image for the DE2-115 with the new boot code in ROM? I would be happy to test it out, and hopefully others with the DE2-115 would try it as well.
Chip's latest ROM_Booter v33d with the special new ROM section commented out
A glance at this shows..
* Delay after SPI reset is still a fixed 50us. My previous posts suggested making this a polling step, as the newer SPI Flash parts have variable delay exits from reset, depending on what they were doing. Data says commands are ignored during this phase.
ie you issue reset (SW, or SPI flash may have a HW reset pin), and then poll the part for a valid response.
Quad and Octal wired parts may be best to use HW reset pins, to cover all possible modes and exits. Users may wire that directly to the P2 reset pin.
Device ID looks suitable, as it is always <> 000000,ffffff, or an alternative may be to wiggle a status bit, and confirm it follows.
It's not clear if simply (re)reading status is enough on a floating pin ?
* Transmit routine still has a 1ms delay for all calls
transmit mov y,##rc_max/1000/4 'wait 1ms to allow host turn-around
As I mentioned before, that represents a long time to add to boot, and it could be smarter to make that 1 char time ?
* ' Receiver ISR - detects maintenance ">" chrs
This still swallows the ">", which I think is not really needed by the string compares (they ignore it anyway), but it does impact other code that might use the serial buffers.
As a test, the faster tx delay code should be able to accept a continual stream (no gaps or delays) of
"> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 ....."
and properly exit and autobaud on that, at any phase.
If the host has buffers, the reply is fewer chars than enquiry, so any buffer overrun should be avoided.
Chip, would it be possible to get an FPGA image for the DE2-115 with the new boot code in ROM? I would be happy to test it out, and hopefully others with the DE2-115 would try it as well.
Currently, there is no real ROM image to try out. It has to be downloaded. Maybe later today (Sunday morning LA time) we might have ROM code ready to put into FPGA ROM. Then if Chip has time he might be able to make a few versions.
So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
Here is v134b code to replace v134a code a few post back.
As above, load new fpga code (BeMicro_A9_Prop2_8cogs_v32d.jic)
Re-power the BeMicro
With pnut, compile and download this code (ROM_v134b.spin2)
With PST, reset P2 by toggling DTR off/on (this goes to the new downloaded ROM code v134b
Type "> " and the "Prop_Chk 0 0 0 0 " and you should see the message "Prop_Ver X" displayed. This verifies we are running the new downloaded 134b code.
Type "Prop_TAQ" to goto TAQOZ or type "Prop_MON" to goto the Monitor. Both will display info automatically.
For TAQOZ, type Ctl-W to display a list of words
For Monitor, type "100L<cr>" or "FC000.FC100L" where L can be lower or upper case
For Monitor, type "<esc><cr>" to goto TAQOZ.
Note quotes not required, and <esc> is the escape character, <cr> the enter character.
Note this code blocks new downloads because it returns "Prop_Ver X" so you know you are running this version. Just edit ROM_v134b.spin and edit this line
ver = "X" ' "F" 'Prop123-A9 / BeMicro-A9, 8 cogs, 64 smart pins <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< temp
back to version "F". You will need to re-power to go back to original fpga rom first, and repeat the above steps.
So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
What do you mean by adding flash and/or SD hardware? Wouldn't we just use the flash and SD hardware already on the FPGA board? I also have a second SD socket wired up on pins other than 58-61, but I don't see how the boot code would use that. As I mentioned in my previous post, I have a DE2-115. I can run tests Sunday evening.
So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
What do you mean by adding flash and/or SD hardware? Wouldn't we just use the flash and SD hardware already on the FPGA board? I also have a second SD socket wired up on pins other than 58-61, but I don't see how the boot code would use that. As I mentioned in my previous post, I have a DE2-115. I can run tests Sunday evening.
No because...
1. Connecting the SD via an internal connection in the FPGA throws up internal pullups
2. The BeMicroCV-A9 has external pullups added to some of the pins which interferes with the pullup detection - I desoldered them on my pcb but couldn't remove those added somehow in the verilog. No time to debug the problem.
You cannot use the SD on other pins because that's not what we are testing now.
But, you can try the monitor and taqoz. However, we will need new code to just test the actual monitor and taqoz code, and it's Mothers' Day here so I won't have time till tonight.
I put the monitor code up weeks ago but no-one tried it
Chip's latest ROM_Booter v33d with the special new ROM section commented out
A glance at this shows..
* Delay after SPI reset is still a fixed 50us. My previous posts suggested making this a polling step, as the newer SPI Flash parts have variable delay exits from reset, depending on what they were doing. Data says commands are ignored during this phase.
ie you issue reset (SW, or SPI flash may have a HW reset pin), and then poll the part for a valid response.
Quad and Octal wired parts may be best to use HW reset pins, to cover all possible modes and exits. Users may wire that directly to the P2 reset pin.
Device ID looks suitable, as it is always <> 000000,ffffff, or an alternative may be to wiggle a status bit, and confirm it follows.
It's not clear if simply (re)reading status is enough on a floating pin ?
* Transmit routine still has a 1ms delay for all calls
transmit mov y,##rc_max/1000/4 'wait 1ms to allow host turn-around
As I mentioned before, that represents a long time to add to boot, and it could be smarter to make that 1 char time ?
* ' Receiver ISR - detects maintenance ">" chrs
This still swallows the ">", which I think is not really needed by the string compares (they ignore it anyway), but it does impact other code that might use the serial buffers.
As a test, the faster tx delay code should be able to accept a continual stream (no gaps or delays) of
"> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 ....."
and properly exit and autobaud on that, at any phase.
If the host has buffers, the reply is fewer chars than enquiry, so any buffer overrun should be avoided.
The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.
Chip, would it be possible to get an FPGA image for the DE2-115 with the new boot code in ROM? I would be happy to test it out, and hopefully others with the DE2-115 would try it as well.
Yes, but I won't have time to make it until about 20 hours from now.
I'll need to get the final code from Cluso99 and Peter Jakacki.
The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.
True, but you have captured 7T and 5T inside the Auto-Baud, so it is quite minimal overhead to either add those, or double one, to give a useful delay value ~ 1 Char time.
To someone trying to sense reset exit and then load code at 1Mbd, that 1ms MIN, is > 100 char times.
So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
What do you mean by adding flash and/or SD hardware? Wouldn't we just use the flash and SD hardware already on the FPGA board? I also have a second SD socket wired up on pins other than 58-61, but I don't see how the boot code would use that. As I mentioned in my previous post, I have a DE2-115. I can run tests Sunday evening.
No because...
1. Connecting the SD via an internal connection in the FPGA throws up internal pullups
2. The BeMicroCV-A9 has external pullups added to some of the pins which interferes with the pullup detection - I desoldered them on my pcb but couldn't remove those added somehow in the verilog. No time to debug the problem.
You cannot use the SD on other pins because that's not what we are testing now.
But, you can try the monitor and taqoz. However, we will need new code to just test the actual monitor and taqoz code, and it's Mothers' Day here so I won't have time till tonight.
I put the monitor code up weeks ago but no-one tried it
Taking a soldering iron to my DE2-115 is probably a showstopper for me. I have tested things using the small prototyping board that plugs into the main FPGA board. If there's a way to wire it that way that would be desirable. The flash chip does sit in a socket on the prototyping board, so pins 59-61 are accessible from the socket. I don't know if pin 58 is available on the prototyping board.
If hardware mods are needed for the DE2-115 it would be good to get specific instructions on how to make the changes.
Cluso99 and Peter, do you have links to your standalone code and documentation where we can just download it? I can try testing it that way.
You can try the last release in the appropriate threads. The changes since have really been code tidy.
Next time on my computer will be tomorrow evening (18 hrs from now) and I will be testing the SD in ROM code just to ensure the booted can pass control to my code.
There are no plans to make any more changes to my monitor or SD code unless we find a problem.
We now have Chips booted passing control to our code (includes YAQOZ). I now have my monitor taking the user settings including baud from Chips booted and Peter is working on the same for TAQOZ. The booted does autobauding.
We've just to verify the pull-up functions correctly and passes control to our respective code. It should go to OnSemi Monday morning. After that Chip said he will make FPGA releases for some of the boards, including DeNano as the boot code will work on a single cog.
Oh forgot, I asked Chip to check the code for sending and receiving characters using the smart pin uart as the code I am using was from a long time ago. I am polling the receive.
...If you plug an SD card in with code in the MBR/VOL or a file, then it boots that ...
Super!!!
This is so important for being able to completely configure a P2 system without needing any tools or special IDE's, etc. This is a really nice feature.
The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.
If you do not want to preserve the baud values, and alternative is to simply remove the tx start delay entirely, as I think that's a legacy from the single-pin boot mode (that is no longer in the ROM I believe) ?
All MCUs and USB links, have Duplex UARTS so they do not care about relative phase of TX.RX.
Chip said that the testing involves a mass of gates which serialise all the outputs from all flops in the chip. This accounts for ~15% of the gates on the die!!! It also impacts the ultimate chip speed as it is also a gating factor :
You seem to be describing JTAG. On many chips it has a second life as a programming and debugging aid for code developers.
Comments
Right. The DIR bits for all smart pins are cleared before their modes are reset via WRPIN. The SPI pin states are preserved, though, so that the booter loaded from SPI can continue to pull more bits from the SPI without needing to reconfigure it.
But zerox clears all bits after the specified bit and does not include the bit itself so therefore an operand of #30 means only the top bit is cleared so it is a ##7FFFFFFF.
This is borne out by this test.
I should have used #29, then. I'm glad you found this.
reset_pins setint1 #0 'disable int1 mov dira,#0 'reset smart pins (avoids output on mode clears) zerox dirb,#29 'clear rx & tx (P62-63) Others??? <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 'decod dirb,#(tx_pin-32) <<<<<<<<<<<<<<<<<<<<< BUT THIS MAKES MORE SENSE (pbj) wrpin #0,#rx_ths 'clear rx_ths mode wrpin #0,#rx_tne 'clear rx_tne mode wrpin #0,#rx_pin 'clear rx_pin mode _ret_ wrpin #0,#tx_pin 'clear tx_pin mode lut_endIt seems to both Peter and I that since all pins P00-P31 are cleared with the MOV DIRA,#0 that you would also be clearing at least all pins P32-P61. Whether in fact you also want to clear P62-P63 is unclear to us.Do you want TX (P62) to remain an output?
Do you also want to clear P32-P61?
https://docs.google.com/spreadsheets/d/1ViilDWiG-hqwsFdjcPgyFfPIfej9bKpKxNTPTigLRIw
Just realised we missed a very important instruction out of the P2
The FPGA code is too big for our forum. Could you please post it thanks.
All,
For those with BeMicroCV-A9 boards...
Here is the latest code v134a as follows (uses BeMicro_A9_Prop2_8cogs_v32d.jic)...
Chip's latest ROM_Booter v33d with the special new ROM section commented out
Peter's TAQOZ BOOTROM(7) from dropbox BOOTROM.spin2 12/5/2018 23:41 using reset_pins instead of inline at start
Ray's SD boot code SD2_133jx/ROM_133k
Ray's Monitor code LSD_v133i/ROM_133k
I have checked out the serial, monitor and taqoz without using pullups. SD and Flash not tested yet.
Pins P58..P61 are for connections to Flash (4-pin only) and/or SD card. There is no internal FPGA connections on these pins and they are NOT connected to the on-board SD card!!
Please test this out urgently as this is scheduled to go to OnSemi on Monday!!!
Don't forget to program the new fpga code into your BeMicro A9 board.
From the monitor enter <esc><cr> to goto TAQOZ.
For instructions/commands see the relevant thread.
For SD, copy a binary file named "_P2_BOOT.BIX" or "_P2_BOOT.BIY" to the card. I posted a simple file in the SD Boot thread.
Chip said that the testing involves a mass of gates which serialise all the outputs from all flops in the chip. This accounts for ~15% of the gates on the die!!! It also impacts the ultimate chip speed as it is also a gating factor
OnSemi also does full testing on every bit of RAM with rolling patterns.
It's all controlled by software far removed from the real silicon. When the software passes, the chip is pretty much guaranteed to work!
IIRC there were 22 processes to make the 350nm P1. There will be 100+ for the 280nm P2. And a process may contain a number of exposures of different masks to create one layer.
And this is a smallish chip on an old generation process. Imagine what goes into making a Xenon CPU or Apple A10 CPU !!!
A glance at this shows..
* Delay after SPI reset is still a fixed 50us. My previous posts suggested making this a polling step, as the newer SPI Flash parts have variable delay exits from reset, depending on what they were doing. Data says commands are ignored during this phase.
ie you issue reset (SW, or SPI flash may have a HW reset pin), and then poll the part for a valid response.
Quad and Octal wired parts may be best to use HW reset pins, to cover all possible modes and exits. Users may wire that directly to the P2 reset pin.
Device ID looks suitable, as it is always <> 000000,ffffff, or an alternative may be to wiggle a status bit, and confirm it follows.
It's not clear if simply (re)reading status is enough on a floating pin ?
* Transmit routine still has a 1ms delay for all calls
transmit mov y,##rc_max/1000/4 'wait 1ms to allow host turn-around
As I mentioned before, that represents a long time to add to boot, and it could be smarter to make that 1 char time ?
* ' Receiver ISR - detects maintenance ">" chrs
This still swallows the ">", which I think is not really needed by the string compares (they ignore it anyway), but it does impact other code that might use the serial buffers.
As a test, the faster tx delay code should be able to accept a continual stream (no gaps or delays) of
"> Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 > Prop_Chk 0 0 0 0 ....."
and properly exit and autobaud on that, at any phase.
If the host has buffers, the reply is fewer chars than enquiry, so any buffer overrun should be avoided.
So who can do a Sunday afternoon/evening test including adding flash and/or SD hardware? What board do you have?
As above, load new fpga code (BeMicro_A9_Prop2_8cogs_v32d.jic)
Re-power the BeMicro
With pnut, compile and download this code (ROM_v134b.spin2)
With PST, reset P2 by toggling DTR off/on (this goes to the new downloaded ROM code v134b
Type "> " and the "Prop_Chk 0 0 0 0 " and you should see the message "Prop_Ver X" displayed. This verifies we are running the new downloaded 134b code.
Type "Prop_TAQ" to goto TAQOZ or type "Prop_MON" to goto the Monitor. Both will display info automatically.
For TAQOZ, type Ctl-W to display a list of words
For Monitor, type "100L<cr>" or "FC000.FC100L" where L can be lower or upper case
For Monitor, type "<esc><cr>" to goto TAQOZ.
Note quotes not required, and <esc> is the escape character, <cr> the enter character.
Note this code blocks new downloads because it returns "Prop_Ver X" so you know you are running this version. Just edit ROM_v134b.spin and edit this line back to version "F". You will need to re-power to go back to original fpga rom first, and repeat the above steps.
Can all these elusive files be zipped up and posted in one place.
It worries me a bit that only a few of us (maybe 5) actually have Bemicro-A9 boards.
No because...
1. Connecting the SD via an internal connection in the FPGA throws up internal pullups
2. The BeMicroCV-A9 has external pullups added to some of the pins which interferes with the pullup detection - I desoldered them on my pcb but couldn't remove those added somehow in the verilog. No time to debug the problem.
You cannot use the SD on other pins because that's not what we are testing now.
But, you can try the monitor and taqoz. However, we will need new code to just test the actual monitor and taqoz code, and it's Mothers' Day here so I won't have time till tonight.
I put the monitor code up weeks ago but no-one tried it
I can email it. Its too big to post on the forum
What is your email addr Brian? PM me as I've lost it
The transmit delay of 1ms at 20MHz is kind of long, but we don't have the actual baud rate, as it was set and forgotten within the auto-baud routine.
Yes, but I won't have time to make it until about 20 hours from now.
I'll need to get the final code from Cluso99 and Peter Jakacki.
To someone trying to sense reset exit and then load code at 1Mbd, that 1ms MIN, is > 100 char times.
If hardware mods are needed for the DE2-115 it would be good to get specific instructions on how to make the changes.
Cluso99 and Peter, do you have links to your standalone code and documentation where we can just download it? I can try testing it that way.
You can try the last release in the appropriate threads. The changes since have really been code tidy.
Next time on my computer will be tomorrow evening (18 hrs from now) and I will be testing the SD in ROM code just to ensure the booted can pass control to my code.
There are no plans to make any more changes to my monitor or SD code unless we find a problem.
We now have Chips booted passing control to our code (includes YAQOZ). I now have my monitor taking the user settings including baud from Chips booted and Peter is working on the same for TAQOZ. The booted does autobauding.
We've just to verify the pull-up functions correctly and passes control to our respective code. It should go to OnSemi Monday morning. After that Chip said he will make FPGA releases for some of the boards, including DeNano as the boot code will work on a single cog.
Oh forgot, I asked Chip to check the code for sending and receiving characters using the smart pin uart as the code I am using was from a long time ago. I am polling the receive.
So that's the latest info.
If you plug an SD card in with code in the MBR/VOL or a file, then it boots that
TAQOZ and the Monitor can go back and forth between them. We use the serial settings passed from the booter and autobaud routine.
Super!!!
This is so important for being able to completely configure a P2 system without needing any tools or special IDE's, etc. This is a really nice feature.
If you do not want to preserve the baud values, and alternative is to simply remove the tx start delay entirely, as I think that's a legacy from the single-pin boot mode (that is no longer in the ROM I believe) ?
All MCUs and USB links, have Duplex UARTS so they do not care about relative phase of TX.RX.