Skip to main content

Use Of Bootloader In SoC Design Life Cycle

Use of bootloader, in SoC design.
SoC in simple terms is collection of required blocks, like USB, MAC, PCI, surrounded to the CPU (generally RISC CPU, ARM).
As a part of SoC development each hardware block is validated for its functionality.
Validation is done register level. Example if we want to test functionality provided by MAC block in our SoC, then these functionality are validated by writing test cases in bootloader (u-boot-1.1.6).
Bootloader will create an environment for the test cases. The test cases are added as commands for each block with different subtests for each block to touch the corner conditions.
To start with U-boot provides generic block test cases, like I2C and many more are getting added day by day.
Format of bootloader commands

int do_hello (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
{
printf("Hello World\n");
}


U_BOOT_CMD(
hello, 5, 0, do_hello,
" hello - Prints hello world\n",
" hello - Prints hello world\n"
" \n" \
);

this will register "hello" as command in bootloader commands list.
Using this structure To validate simple GPIO functionality we write GPIO related test cases, so as to test GPIO features like GPIO interrupt.

MAC Block Validation test cases could be
  1. Link Up/Down test
  2. a. Validates PHY interface.
  3. b. Validates link negotiated by PHY
  4. Link Interrupt test
  5. a. Validatess the Link interrupt
  6. Digital loop-back test in full duplex mode
  7. a. Validates data path in MAC controller in varous link speeds
  8. 10/100/1000Mbps
  9. b. Validates normal frames (60-1514)
  10. Analog Loop-back in full duplex mode
  11. a. Validates PHY interface
  12. b. Validates Data path in MAC as well as PHY
  13. External loop-back test
  14. a. Validates PHY interface
  15. b. Validates Data path in MAC as well as PHY
  16. Digital Loop-back test in half duplex mode
  17. a. Validates data path in MAC controller
  18. DMA interrupt test
  19. a. Validates th MAC interrupts
  20. Incremental test
  21. a. Validates Data pathin MAC controller for varrying packet length
  22. External Incremental test
  23. a. Validates Data path in MAC controller and PHY for varrying packet length
  24. Promiscuous and MIB
  25. a. Validates Promiscous and Normal mode
  26. b. Validates the statistic count registers
  27. Pause Frame test
  28. a. Validates Pause frame Transmit and recieve
  29. b. Validates the statistic count registers
  30. Multicast frame test
  31. a. Validates the Hash table entry for Multicast filter
  32. b. Validates drop and pass of a Multicast Frame
  33. c. Validates the statistic count registers

Comments

Popular posts from this blog

Dotnet, .Net 3.5, 2.0, C# Interview Questions

Few questions on dotnet, C# 2.0, 3.5 On Object oriented concepts 1)What is inheritance with e.g 2)What is polymorphism -function overloading -Function overriding -virtual keyword use -Static keyword and use -Abstract classes -Interface -Object 3)What is threading and how do we use in realtime application(cognizant) 4)What is threadpooling, lock, monitor(write code sample) 5)Architecture of current project 6)Session state, diffrent types of state management. 7)What is Application_Start, how it works. 8)Type of authentication in asp.net 9)How to configure ASP.NET application. 10) What is Impersonation. 11) What is WebService, WSDL, UDDI, Discovery, asmx files. 12) How to implement WebService and use it. 13) When to use WebServices. 14) WPF, how to implement(BOA) 15) Testing concvepts. 16) Test attributes 17) Flow of Automation Test Method execution 18) Features of dotnet 3.5 19) CLR, garbage collection 20) Finally block 21) Manifest, Metadata, MSIL 22) Assemblies, Type of assemblies, str...

Remote debugging for ARM target board

Remote debugging for ARM target board With GDB one can both trace and modify code and data flow, and otherwise analyze the behavior of code, without explicitly changing any of it. Rather than run a full-blown instance of GDB on the target platform, you can use GDBserver , a program that lets you run GDB on a different machine than the one on which your program is running. The advantage of using GDBserver is that it needs just a fraction of the target resources that GDB consumes, because it implements only the low-level functionality of the debugger -- namely setting breakpoints and accessing the target processor registers and read/write application memory. GDBserver takes control of the application being debugged, and then waits for instructions from a remote instance of GDB running on a development workstation. Remote target needs to have debugging stub (gdbserver), The gdbserver is also referred to as the 'stub' and must be cross-compiled for that targ...